0

I have the following situation: I have to create a website and a web service that will share a part of the functionalities.

This is why I do not want to write code twice.

I have thought of the following architecture:

MyApp.BusinessLogic --> here we save the DataModels to the database

MyApp.DataAccess -> DataModels & Entity & mapping


MyApp.UI.Models -> ViewModels

MyApp.UI.ServiceLayer -> Acceses the Business Logic, creates the UI ViewModels for the website, and transforms the ViewModels back into DataModels for saving with the help of the BusinessLogic Layer

MyApp.WebSite


MyApp.WS.Models - >Ws Models, these will be the objects passed between the client and the WS

MyApp.WS.ServiceLayer -> Accesses the business Logic, creates the WS Models for the web service, and transfoms the WS.Models back into DataModels for saving with the help of the BusinessLogic Layer

MyApp.WebService


  • Is the architecture overkill ?

  • What problems will I encounter ?

  • Will I have problems with the controllers in the ASP.NET MVC website ?

1

I think the models being in separate projects I think is overkill. You should have your models and controllers, along with View Models in their relevant projects.

Depending on your architecture, it may make more sense to have the service with the web site. I'd do this if it were only one or two services, for several services or if you need it to run independently of the web site then I'd have it as a separate service.

With regards to the sharing of functionality, look into data transfer objects to transfer lightweight implementations of your objects and object graphs between layers, particularly with the service layer as you won't necessarily want to transport deep graphs. Look into the adapter pattern.

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.