How to refactor services into API, repository and caching (.NET)?

Question

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:

1. Business logic, caching logic and database logic is not separated, but one big pile in a Service
2. Impossible to easily use a new caching, database or similar.
3. 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 a IRepository? 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?

Answer 1

Does this architecture even make remotely sense?

It seems reasonable to me. You've correctly identified the layers you need and what behaviour belongs in each of them.

Which objects would be injected where? Would a service inject repository so a CustomerRepository that derives from a IRepository? How is the caching actually done / called?

I'm pretty sure you're talking about dependency injection? If so, yes, the service layer would inject the repo layer, and the api layer would inject the service layer. Pretty much every dependency to something doing business logic for the system should be injected, so that you can unit test.

I'd suggest starting off with a direct database cache if you don't already have one, and then possibly adding a higher-level cache if you still have demonstrated performance issues in production. If your API is RESTful, you could go a step farther and use a caching proxy such as squid in conjunction with properly set caching headers. The convenience of this will depend on your stack - NHibernate has L2 caching support built in, for instance.

This leaves me with 3 representations of an object. Model, API viewmodel and website viewmodel - seems quite timeconsuming

Yup. The tradeoff is more time for more flexibility. In addition to the attachment issue you saw, a single representation tied to all three layers may be very limiting later on. For instance, you can't decide to have your API release a single resource that's a combination of two or more database tables. Any change to the representation will impact the whole application, which may not be desirable. You may also find, over time, that layer-specific information creeps into your representation, which will add dependencies that really don't belong in the other layers.

Where can I find some examples about this that will help me?

Out of scope. :-( Google is your friend? Try something like .net n-tier example. Alternately, if you prefer real code, you could troll github and see if there's anything on there to work off of.