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?
Improve this question

    2 Answers 2

    Reset to default
    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.

    Improve this answer
    8
    • 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
      CommentedJun 2, 2018 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
      CommentedJun 2, 2018 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
      CommentedJun 2, 2018 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
      CommentedJun 2, 2018 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
      CommentedJun 3, 2018 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

    Improve this answer

      Start asking to get answers

      Find the answer to your question by asking.

      Ask question

      Explore related questions

      See similar questions with these tags.