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 ?
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.
0