Architecture regarding MVC controller vs. separate Web API, how many projects?

Question

In the past, I've always thought about exposing methods that will be consumed on the client side in an separate Web API project. Currently, I'm diving deeper into ASP.NET Core MVC and now understand what controllers are for. (I come from an ASP.Net webforms background)

Given that I might program an app (e.g., with Xamarin) in the future where I would consume most of the same methods from the Core MVC project, it would make sense to separate most of the functionality into a separate api.xxx.com Web API project.

From my point of view, ASP.NET Core MVC controllers are very similar to Web API projects and I fail to see a big difference in terms of consuming them. Basically, I'm confused as to whether have two projects (Core MVC project and separate Web API project) or just a single one.

1. Should I use two projects or just one? What are the advantages and disadvantages? If I use two, based on which criteria do I decide where to add new code? Can I move almost any (what's the exception) code from the controllers in the Core MVC project into the Web API project? Is that a good approach or a bad one?
2. How should I handle the client side login? I know that I can get token-based authentication with OWIN for my Web API project but how should I combine the authentication from the ASP.NET Core MVC project with the Web API project?
3. Let's assume that I decide to just use one project for both. How much overhead is there if the Xamarin app would call the MVC project all the time instead of the Web API project?

Answer 1

As Crish already mentioned that Start small into single project and eventually you can move things. Later on you can decide to have multiple projects. That's a good start however it mixes the things - all of your UI (cshtml or angular or whatever UI you want to have), all your data contracts, API, Controllers and everything.

Why we have MVC and Web Api technologies out there?

It's a big question and you have your answer in that question : Separation of concerns. It's a key while designing the application architecture. The idea is to avoid co-locating different concerns within the design or code. For example: You have the MVC Controllers that returns the views, and you have the other API controller which returns only Data. If you mix these things together I think it's a violation of that rule. While designing the architecture separation of concern is key component of Building layered applications.

Separating all the logics across different layers will allow ANY functionality to be added/remove later and it even allows you to support other third party consumers. As long as all these abstractions are properly grouped then you will achieve the good architecture that will be the best from any perspectives.

My suggestion is to use the DDD Pattern with SoC principle. BUT, all these efforts make sense if you have Big application that you need to extend over the time. I would start documenting all the modules you might have. If I would follow the above Pattern and Principle, I would end up having individual api.xxxmodule project for all the modules - DDD Pattern. I would have MVC, Authentication/Authorization API Project as separate.

If you follow those 2 principles, your application will end up having separate module for everything - each module act as an Individual app!

Hope you can imagine the benefits of them from all the perspectives. It has a huge huge benefits in term of managing, extending, changing, scaling, development, etc. Because each pieces works as an individual app, you can focus on all modules one by one rather than thinking mixed.

Answer 2

There's a lot to unpack in your question. First to your general inquiry:

From my point of view, ASP.NET Core MVC controllers are very similar to Web API projects and I fail to see a big difference in terms of consuming them. Basically, I'm confused as to whether have two projects (Core MVC project and separate Web API project) or just a single one.

That's because there's functionally no difference. In ASP.NET Core, controllers are controllers are controllers. The designations of MVC/Web Api are merely about style. In the former, you'll return views, while in the latter, you're return something like JSON.

Now in truth, the styles have diverged a bit more in later versions of ASP.NET Core. API controllers now usually inherit from ControllerBase rather than Controller and have the [ApiController] attribute applied. However, even this is not a real difference. The attribute just adds some sugar that makes building APIs a bit easier: returning 400 automatically when ModelState is invalid, switching the default bind from FromForm to FromBody, etc. It's all stuff you could do with MVC just as well. Using ControllerBase just excludes stuff included in Controller that's unnecessary for APIs. There's no View method to return because you won't be returning views from an API, for example. Everything else functions the same.

Long and short, it's pretty much about how you implement the controller, not any specific choice of using MVC or Web Api.

Now, as to your specific questions:

1. Should I use two projects or just one? What are the advantages and disadvantages? If I use two, based on which criteria do I decide where to add new code? Can I move almost any (what's the exception) code from the controllers in the Core MVC project into the Web API project? Is that a good approach or a bad one?

Again, a lot here to unpack. Simply, there's no right answer, and frankly, you don't have to decide right now. You can start with just one project mixing and matching MVC and Web Api controllers. Then, if you find a specific need, you can always create a new project and move your Web Api controllers over there. It just depends on your requirements and the needs of your application(s), which unfortunately no one can speak to but you. My best advice always, though, is to start small. Get out of the weeds and just build something. You aren't carving in stone; anything can be refactored later.

2. How should I handle the client side login? I know that I can get token-based authentication with OWIN for my Web API project but how should I combine the authentication from the ASP.NET Core MVC project with the Web API project?

Once you start talking about authenticating multiple apps, you really need to start looking at a centralized identity solution. There's out of the box, low config solutions like Azure AD or Auth0, or you can roll your own with Identity Server. It basically boils down to what you're willing to pay and how involved you want to be.

3. Let's assume that I decide to just use one project for both. How much overhead is there if the Xamarin app would call the MVC project all the time instead of the Web API project?

I don't think you're looking at this the right way. Requests are requests and the question is merely one of scale. The difference between one app (one project) and multiple is simply whether all the requests go to one place or many. However, you can always both vertically (resources) and horizontally (more instances) scale even just one app. So, the performance isn't honestly a concern here. In either form, you're scaling, just in different ways.

Answer 3

It depends of the complexity that you aim for. In my point of view the clear way the best. With ASP.NET Core using Domain-Driven Design concepts and patterns, it's a good way to go. Check Clean Architecture from Steve Smith, and give it a try.

example how you can organise it.