Home/ Questions/Q 497265
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T05:45:54+00:00

I’m considering strategies for a simple-minded CMS implementation for an ASP.NET MVC site. The

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0