Thanks for sharing!

Great!

Thanks for sharing!

I am glad it was helpful.

👍🏻

I mostly agree with the "it depends", although I've fully moved over to minimal APIs over controller-based APIs now. I don't see the need for controllers and they add a layer of complexity that doesn't seem to be needed. You can do everything you need in a minimal API, including testing, separation of concerns, decorating, and more, but it is in a simpler format with less unnecessary ceremony.

Mvc is a design pattern. You can do MVC on whatever stack you want. It's about segregation of items

The situation you are describing sounds like an abuse of MVC. Controllers with lots of actions tend to be really messy and hard to maintain. MVC was developed in a time when the only option for C# on the web was WebForms. MVC provided a more structured, testable, modular approach to web development. It became really popular because of that. Now, we have lots of options for development. Razor Pages works well for single pages (index, error, about us, etc.) where there isn't a lot of interaction. MVC can do more complex code separation for larger server-side sites. We used to use it to provide data to client-side applications such as React, but that's not really the best solution anymore. Now we just use API for that. Server-side in general has fallen out of favor because people want rich, client-side interactivity. That's why we now have Blazor Server and Blazor WebAssembly. Two options to give us that client-side interaction while still using C#.

If you mean the built-in templates, they are almost useless in a large organization. The code of the organization will quickly grow beyond them to the point that the original template had little, if any, impact. In a large organization, it is better to establish coding standards and then apply them to your specific projects. That can include creating your own templates.

I personally prefer breaking features out into modules (for monoliths). So for example, there's a Loyalty Points feature, just create a new folder... A new module. And have a single point of connection to the rest of the code. Then, there, a developer has freedom to choose any code structure they want to apply. Just for all the routes, controllers, service, models or any combination of these which are created within that module. Faster development with the devs coding style innately being used. And easy switching off and on that module. Also, close to zero merge conflicts. . And architecture could be made as simple or as complex as the requirement of the module. . This approach is something I experimented and created for a startup that started out as monolith, but was soon expected to grow to big scales.... And we needed the code seperation for easily breaking it up into a micro service architecture

Thanks!

Excellent!

They are really great.

Thanks for sharing!

That difference is negligible, I believe, though.

You are welcome.

You are welcome.

There is still a need for an API. It is just often hidden. For example, with the new Blazor (they've dropped the "united" word even though it was the best way to describe it), if you use Auto or WebAssembly, you get two projects. One is the front-end project and the other is the back-end project. The back-end acts as an API for the front-end.

@@IAmTimCorey That's my current confusion. With WebAssembly deployment, how does the interaction with a Server Side resources happen if one doesn't also build an API layer over the Data Source and to avoid repeating myself, do I use the API for my Blazor Server components. My hope is that by digging into your latest Blazor course (with .NET8), I'll see how this unlocks. Thanks for the insight on end-points vs. MVC!

Interesting. I haven't found full APIs to be any easier to debug. I've found that it is just a different way to do the same thing.

Technically maybe, but it is more preference.

@@IAmTimCorey I always get suspect on questions of performance when it comes down to fractional differences with function calls. Unless they are being invoked 1000's of times a second, it rarely matters, but its a honey trap for the ocd tendencies of the coder psyche 😁. 99.99% of the time, performance is impacted by algorithms, i/o and app design.

Microsoft provides the full API project type (with controllers) for both .NET Framework and .NET. They also provide the Minimal API project type for .NET. Finally, an Azure Function can be a very small API (single endpoint). But that's just the project types from Microsoft. Practically every programming language provides a way to create an API. APIs power a lot of the web and mobile applications out there, plus some desktop applications. If you build an API in C#, the best choice for a new project would be either a full API or Minimal API in .NET 6+ As for your question about which ones can be handled by "Microsoft Technology" (I'm assuming you mean a C# application), the answer is any of them. An API is designed to be processed by anyone. That means you can write an API in Java and call it from C#. The same is true in reverse.

You're welcome!

The problem is that concrete advice on which to choose is almost always wrong. You need to make the right call based upon your specific situation.

@@IAmTimCorey If only someone had advice on which things to take into account, though. /s

That list includes: * your team's skills * how well your team can train up in minimal APIs * your existing code * the versioning of the libraries you depend on * the features you need to rely on in C# (more preference than prescriptive) * greenfield or brownfield API * any existing conventions or practices that would weight a choice * your preferences And this is a simpler issue, since both can do similar things.

👍🏻

If you close your eyes, the problem goes away. 😉 Sorry we can’t fix it any other way.

How does a controller add more of a separation of concerns compared to an endpoint? I can put endpoints in their own class(es) easily enough. They aren't any more coupled than controllers are.