I am working on a .NET project with, which started out as a prototype that now has to scale. We have the ASP.NET MVC stack with Entity Framework (code first).
I would like to hear how to scale this into a "proper architecture" with API, repository that handles caching and so forth probably.
Note: I am not looking for a discussion (which isn't meant to happen on this site), but just how this is usually solved.
Situation today:
We have a website, service project, model project and database project:
So in practice our website uses the Service, Model and Database assembly. The service returns our Model objects, which it retrieves from direct use on Context.cs.
So in practice we could for instance call CustomerService
in Service project, which derives from ICustomerService
from Model project. This would call Context
in Database project directly, which then return a Customer
object from Model project.
Top experienced issues with today:
- Business logic, caching logic and database logic is not separated, but one big pile in a Service
- Impossible to easily use a new caching, database or similar.
- A lot of inconsistency issues with DB objects, being attached/detached from EntityFramework directly
My thinking:
I was considering an architecture such as this:
Where:
- The API would have its own viewmodels that work as our Resources the consumer of the API expects
- The service layer would let Repository handle all database activity.
- We would be able to decorate model objects with caching
But this leaves me with a lot of questions:
- Does this architecture even make remotely sense?
- Which objects would be injected where? Would a service inject repository so a
CustomerRepository
that derives from aIRepository
? How is the caching actually done / called? - This leaves me with 3 representations of an object. Model, API viewmodel and website viewmodel - seems quite timeconsuming
- Where can I find some examples about this that will help me?