views:

40

answers:

2

Hello,

I'm considering strategies for a simple-minded CMS implementation for an ASP.NET MVC site. The simple-minded part is that I've abstracted the values used in various partial views, all of which are user controls that share identical CSS layouts. So I'm populating the custom values in the identical partial views from the database where I can modify them occasionally using CRUDs.

The not so simple part is a reasonably efficient and logical abstraction of a standard UI element as a sql table row. But putting that aside...

I know I'm going to use some super-models to hand to each page the pre-configged models for the partial views. But if they are pre-configged and pre-loaded, where to put them until called?

The part that makes me think I'm a little insane to go this way is the load time for what is essentially static data. But then again, SharePoint!

So (I think) why not load it all in application_start? Why not? I answer! Then I get to use IoC for something that google returns not one link to good information from even one smart person who has ever considered that it might be a sane idea.

So does anyone have a better idea for populating a Model from the database using an IoC container other than putting a repository call in the constructor?

And then, does anyone think that putting these static-data models in an IoC container accessible to the controllers is a dumb idea?

Thanks,

S. Machino

+2  A: 

Following several SOLID principles, keep your stuff as single-minded as possible. For semi-static data, first create a Repository that loads this data. This will load the data for every request. It works, but probably doesn't perform so well, but now you have the implementation you need.

The next thing you can do is to Decorate the first Repository with a caching Repository. This CachingRepository will read from the decorated Repository only once, and then keep data in memory.

Thus you respect Separation of Concerns.

If you scope the CachingRepository instance to be a Singleton, it will live until the application is recycled, effectively keeping the cached data in memory.

Mark Seemann
+1 for singleton lifetime repositories and designing for simplicity. In my current project I have some data sitting in a slow web service, but I don't even bother to improve it since it's behind repository and I can do this literally any time.
queen3
This is excellent! Thanks very much.
Stato Machino
+1  A: 

You may want to consider using the OutputCache attribute in your design. You can decorate your action methods that will return static data with this attribute and the framework will take care of caching.

Of course, you still need to handle when to invalidate the cache.

Matt Spradley
Yeah. OutputCache rocks! :)
Arnis L.