asp mvc: database calls and caching, introducing a 4th entity?

Question

Here's the architecture of my app:

I have a data access layer in a seperate assembly, with a class containing methods such as List_XYZ, Insert_XYZ, Update_XYZ etc. All methods return or use objects from an object model I've created, which also resides in the data access layer assembly.

Inside my mvc app, I've created views, controllers and models. Inside the models I've stuck the logic to call the data access layer and populate themselves from the data access layer object model classes as well as logic to create the data access layer classes and pass them to the data access layer for inserts updates:

|-----MVC Application---------||-----------Data Access Layer------|
View -> Controller -> Model  <-->  Object <--> Data Access Layer <--> Database

Now, because some of the views are getting a little more complex, I need to get a list of looks for drop downs as well as get the details for the object I'm editing or viewing, and I am adding logic for caching, I'm wondering if the model is really the spot for this data. I thought about moving the communication between the MVC model and Data access layer to the controller instead, but I like having a nice lean controller and model, so am thinking about a 4th entity. I know there's been lots of discussion around where to put business rules/database calls should it be in the controller or model, but haven't seen much discussion around introducing a 4th entity. Bad idea?

Answer 1

4th entity meaning 4th layer? For lookup tables, we have a class which contains all lookups. It's then pretty trivial to use ASP.NET Caching to cache each call. For example, this lookup class might contain calls such as Fetch_States(), Fetch_Statuses(), Fetch_Colors, etc. For example:

IEnumerable<RefTable_State> Fetch_States()
{
    if HttpContext.Current.Cache["States"] == null
    {
        HttpContext.Current.Cache.Insert("States", DAL.Get_States());
    }
    return (IEnumerable<RefTable_State>)HttpContext.Current.Cache["States"];
}

We simplify it a bit via a base cache class, but that's the general idea.

Answer 2

If I am reading your question correctly, you are using an almost active record pattern in your view models to hide domain / data access interactions so you can keep your controllers lean and now all the complexity you have added is causing you pain?

View models should be almost dumb data containers focussed on presentation logic, not getting the data from the database etc, all you have done is shifted logic from the controller ( where it should be ) to the model.

Can I suggest you remove the data access code from the model, use your controller actions to retrieve the appropriate data and something like object mapper to map the data to/from your view models.

Caching should be applied at the data access layer - you are trying to increase performance by reducing the number of database hits - and that caching should be transparent to the users of the data access layer.

As an aside, are you really sure you have a performance issue? Have you run some load tests to determine the current performance profile and hotspots that require performance fixes?