使用 IOC 预填充 MVC 模型 - 缓存的替代方案？
我正在考虑为 ASP.NET MVC 站点实施简单的 CMS 实施策略。简单的部分是，我抽象了各种部分视图中使用的值，所有这些都是共享相同 CSS 布局的用户控件。因此，我将自定义值填充到数据库中的相同部分视图中，我可以偶尔使用 CRUD 修改它们。
不那么简单的部分是将标准 UI 元素作为 SQL 表行进行相当有效和逻辑的抽象。但抛开这一点......
我知道我将使用一些超级模型将部分视图的预配置模型交给每个页面。但是，如果它们是预先配置和预先加载的，那么在调用之前将它们放在哪里？
让我觉得我这样做有点疯狂的部分是本质上静态数据的加载时间。但话又说回来，SharePoint！
那么（我认为）为什么不将其全部加载到 application_start 中呢？为什么不呢？我回答！然后我开始使用 IoC 来做一些事情，即使是一位聪明的人也认为这可能是一个明智的想法，谷歌不会返回任何良好信息的链接。
那么，除了在构造函数中放置存储库调用之外，是否有人有更好的想法使用 IoC 容器从数据库填充模型？
然后，有人认为将这些静态数据模型放入控制器可访问的 IoC 容器中是一个愚蠢的想法吗？
谢谢，
S.马奇诺
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
遵循几个坚实的原则，让你的员工尽可能专心致志。对于半静态数据，首先创建一个加载此数据的存储库。这将为每个请求加载数据。它可以工作，但可能性能不太好，但现在您已经有了所需的实现。
您可以做的下一件事是用缓存存储库装饰第一个存储库。这个 CachingRepository 只会从修饰的 Repository 中读取一次，然后将数据保留在内存中。
因此，您尊重关注点分离。
如果将 CachingRepository 实例的范围设置为 Singleton，它将一直存在，直到应用程序被回收为止，从而有效地将缓存的数据保留在内存中。
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.
您可能需要考虑在设计中使用OutputCache属性。您可以使用此属性装饰将返回静态数据的操作方法，并且框架将负责缓存。
当然，您仍然需要处理何时使缓存失效。
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.