2

enter image description here

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?

  1. Should we have different projects for Web API and MVC/UI?
  2. Should we have ViewModel only for MVC applications and return plain DTO to the Apps and let them build ViewModel for their UI?
  3. 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?
  4. The adapter classes (to convert DTO to entity and vice-versa), it should be in a separate project OR same project?
2

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.

  • 1
    Could you please share some example project that has service layer b/w business logic and website? What is the primary role of this layer? – maverick Jun 2 '18 at 6:16
  • Also, if we have to serialize the entities to pass it to the website/api, we will have to refer Entities project from MVC & Services project. Should we do this OR just keep reference of DTO project in the MVC & Services project? – maverick Jun 2 '18 at 6:23
  • I am making some assumptions about your code, that your business layer consists of OOP style entity objects with methods? an an MVC action typically does more than just use a single entity? If so, The service layer is the code you currently have in your controller/actions which is not presentation logic. – Ewan Jun 2 '18 at 16:01
  • eg. maybe you have a buy action which loads a basket, customer, address etc calls a few methods and saves the result. Make that service.Buy(basket) – Ewan Jun 2 '18 at 16:04
  • 1
    well the buy button on the web page and the buy button in the app do the same thing right? so there should be a point where you can share code and remove duplication. plus its good to separate from you hosting layer – Ewan Jun 3 '18 at 22:08
0

Your MVC/UI project should communicate via WebAPI. Then you can reuse the WebAPI for both Mobile and Web application. You can not use business layer alone to share it with Web and API until you have separate service layer(which is not required).You have to deploy the solution as API and Web application separately

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.