C# – ASP.NET Web API and MVC Architecture for Web Application

asp.netasp.net-mvcasp.net-mvc-web-apicn-tier

We have a single solution Visual Studio web application with multiple projects.

One of the projects (Services project) has APIs for our App clients (Android/iOS). There's separate project for MVC application that powers our Desktop and Mobile website. There's one project for DTO that has POCO classes for request/response objects. One project is for Entities that has all our business Entities.

The ViewModel classes are saved in the MVC/UI project itself. The Adapter classes (to convert DTO to entities and entities to DTO) are in services project and in MVC/UI project respectively.

For Android/iOS the request-response looks like: Request parameters come to the services project and are mapped as DTO through service's project adapters, this DTO is converted to Entity and passed to BL, DAL, DB/MicroServices. The response comes back to the services project as Entity and gets mapped to a DTO through Adapter classes. This DTO is passed as response to the clients.

For website (mobile & desktop) the request-response looks like: Request parameters come to the MVC/UI project and are mapped as DTO through MVC/UI project adapters, this DTO is converted to Entity and passed to BL, DAL, DB/MicroServices. The response comes back to the MVC/UI project as Entity and gets mapped to a ViewModel through Adapter classes. This ViewModel is passed to the view which generates the HTML and passes HTML to the clients.

The primary difference between DTO and ViewModel we have is that DTO are flat objects while ViewModel might have nested objects too. Also, ViewModel might have composite fields i.e. fields like FullName (combination of FirstName and LastName) while DTO will only have simple properties like FirstName, LastName. The reason is that we want to give flexibility to Apps i.e. they might want to show FirstName in a different font as compared to LastName.

There are few queries we have regarding the above architecture?

Should we have different projects for Web API and MVC/UI?
Should we have ViewModel only for MVC applications and return plain DTO to the Apps and let them build ViewModel for their UI?
Is it correct to accept only DTO from the clients and return back only DTO/HTML to them? Is it necessary to convert DTO to entity for each request and vice-versa for each response?
The adapter classes (to convert DTO to entity and vice-versa), it should be in a separate project OR same project?

Best Answer

It looks like you are missing a service layer between you business logic and your websites.

If you draw in a horizontal slice on your diagram for it you can see immediately that you have a choice of whether to:

Move you existing "Services Project" into that layer and have the Website and Mobile Clients both consume it.
OR to create a new project comprising of the orchestration of you Business Objects which two slimmed down WebSite/WebAPI projects consume.

I wouldn't have more projects for the adaptors myself, as I would see that as the main role of the WebSite/WebApi after having moved any non view related logic to the service layer.

Is it correct to accept only DTO from the clients and return back only DTO/HTML to them? Is it necessary to convert DTO to entity for each request and vice-versa for each response?

You don't have much choice. You have to serialise the Entity, whatever you serialise it to is the DTO or ViewModel.

Your only question is really how similar the ViewModel/DTO is to the Entity. Usually the ViewModel/DTO simplifies the work of the View/Client by adding fields, flattening data etc as you say. But the simplest way is sometimes just to serialise the Entity as it is.

Related Solutions

C# – ASP.NET MVC SoC when dealing with back end objects (design decision)

This is a common point of confusion with ASP.NET MVC, mostly because MVC is so un-opinionated about how your application should be built. @MikeSW makes a good point: it's important to realize that MVC is a UI pattern, but more importantly, you should realize that it's just a pattern. It's not law, the framework won't complain if you do something different.

I'll tell you how a typical ASP.NET MVC project develops, because there's a reason why it's typical. You have domain layer. That could include a DAL, services, whatever. For many, this is just Entity Framework, but if you're building anything larger than a ToDo app (and maybe even for that), you're going to want to abstract that out.

Now, because MVC comes with Entity Framework, the common assumption is that your entities are your Model of MVC. That's a very poor assumption. Entities are dumb - intentionally dumb. They're not really intended for anything but data transfer to and from the database. A Model should be the opposite of that: it should hold all your business logic for the application (or at least that piece of the application. In that way, a view model is closer to the Model of MVC, but even then, it's not all-ecompassing. I would say that your Model is some combo of your view model plus your domain layer. Regardless, the point is that if you intend to use entities as an end-to-end, be-all-end-all Model, at some point, it will bite you in the glutious maximus. It's not a matter of if, but when.

My recommendation is the following:

Database -> Entity Framework -> Domain Layer -> Controller -> View Model -> View

And, back the same way.

Your domain layer will utilize Entity Framework (but this could later be substituted with a Web API, WCF Service, whatever) to retrieve your entities. Your controllers will map your entities to view models and vice versa and then your views will use your view models. For POST operations, your controllers receive view models, map those to entities, and then send them through the domain layer down to be created/updated/whatever. All big MVC projects are built like this or in some minor variation of this, and for a good reason: if you don't do it this way now, you'll only have to do it this way later, with much more time and expense on the tail-end.

C# – ASP.NET MVC should I reference the DAL from the UI

I don't generally expose the DAL directly to the UI.

Normally, I create model classes as close as the final UI representation as possible. And wrappers that translate / transform one or more entities from the DB into those.

This, as you said, might seem a little bit redundant, but it is useful when the viewmodel gets complex enough so that you have different representations for querying multiples objects vs updating / inserting / deleting those.

It is actually inspired on the CQRS design pattern, where different representations are used for queries (the new wrapped classes you were talking) and updates back from the viewmodel to the entities using commands.

Here is a very good link from Martin Fowler's blog explaining CQRS.

I actually use Web API 2 for the commands as the web applications are really client-side intensive (KnockoutJS etc).

Best Answer

Related Solutions

C# – ASP.NET MVC SoC when dealing with back end objects (design decision)

C# – ASP.NET MVC should I reference the DAL from the UI

Related Topic