We've got a .NET Solution consisting of a MVC Website and a bunch of libraries for business and data logic. In the past the website was the only way to interact with our business logic, but we're finding ourselves having to share this logic between various systems, and we've decided to expose it via a REST API.
The typical flow of information between the current architecture is:
UI -> Model (Controller) -> Model (Business Logic) -> Entity (Data Logic) -> DB
If I were to move the business logic library into a REST API, obviously I need to retrofit the MVC website to consume it so we continue business as usual.
Should I leave the existing method signatures on the business logic as they are, with the model objects as the parameters, or should I consider refactoring this?
public List<ClaimSearchEntity> Search(ClaimSearchRequest request)
Here's something to give an idea of the dependancies between the layers:
MVC.App -> Application.Logic
Application.Logic -> Application.BusinessLogic
Application.BusinessLogic -> Application.Data
-> Application.Models
Application.Data -> Application.DataLogic
-> Application.Entities
-> Application.Mappings
Something else I thought might be helpful in this regard is returning meta data for the API requests by exposing the model fields as JSON. Something like JIRA does.
I need to find a balance between getting the job done quickly and getting it done properly. Do you have any suggestions or alternatives for my approach?
MVC.App
next to the existingMVC.App
that provides the web-UI. All libraries below that level should be unaware of which application is calling them.