尝试提高MVC3的效率+统一项目
我有一个使用 Unity 进行依赖注入的 MVC3 项目。
有一个主要的 MVC3 项目、一个位于 MVC3 和数据层之间的“域”类库，以及一堆构成数据层的类库。
(MVC3) – (domain) – (data tier)
这是域类中的服务构造函数之一的示例：
public DomainModelCacheServices(
Data.Interface.ICountryRepository countryRepository,
Data.Interface.ILanguageRepository languageRepository,
Data.Interface.ISocialNetRepository socialNetRepository
)
每次调用构造函数中包含 DomainModelCacheServices 的控制器时，都会构造一个新的 DomainModelCacheServices 对象，加上三个DomainModelCacheServices 构造函数中的存储库类。
我不敢相信这是有效的！
更糟糕的是 DomainModelCacheServices 类是一个缓存类。它加载永不改变的数据列表，并将它们保存为静态数据。但它仍然需要为每个引用构建三个存储库类！
如果我给 DomainModelCacheServices 单例的生命周期（永远），我必须确保它是线程安全的，如果有一天我获得数百次点击，将会有很多锁定。
我可以将构造函数更改为：
public DomainModelCacheServices(
IServiceLocator serviceLocator
)
我不知道为什么，但这看起来不对。构造函数在视觉上变得毫无意义，我必须在域类中引用 Unity，并以某种方式使域类知道 MVC3 应用程序拥有的 ServiceLocator。也许松耦合太松了？
也许构建所有这些类并不像看起来那么低效，我不应该担心它？
如果 Unity 支持“惰性”构造函数参数，那就太好了。但事实并非如此。
那么，关于如何使 MVC3 + Unity 项目更加高效，特别是在领域模型设计方面，有什么想法吗？
感谢您的阅读！
I have an MVC3 project that uses Unity for dependency injection.
There is a main MVC3 project, a “domain” class library that sits between MVC3 and the data tier, and a bunch of class libraries that make up the data tier.
(MVC3) – (domain) – (data tier)
This is an example of one of the service constructors in the domain class:
public DomainModelCacheServices(
Data.Interface.ICountryRepository countryRepository,
Data.Interface.ILanguageRepository languageRepository,
Data.Interface.ISocialNetRepository socialNetRepository
)
Every time a controller is called that has DomainModelCacheServices in its constructor, a new DomainModelCacheServices object is constructed, plus the three repository classes in the constructor of DomainModelCacheServices.
I cannot believe this is efficient!
What makes this worse is that the class DomainModelCacheServices is a cache class. It loads lists of data that never change, and holds them as statics. But it still needs to construct three repository classes for every reference!
If I give DomainModelCacheServices the lifetime of a singleton (forever), I have to ensure it is thread-safe, and if the day comes when I am getting hundreds of hits, there’s going to be a lot of locking.
I could change the constructor to this:
public DomainModelCacheServices(
IServiceLocator serviceLocator
)
I don’t know why, but this doesn’t look right. The constructor becomes meaningless to the eye, and I have to reference Unity in the domain class and somehow make the domain class aware of the ServiceLocator owned by the MVC3 application. Maybe the loose-coupling can be too loose?
Maybe constructing all these classes is not as inefficient as it looks I shouldn’t worry about it?
What would be nice is if Unity supported “Lazy” constructor parameters. But it doesn’t.
So, any ideas on how to make an MVC3 + Unity project more efficient, specifically in the domain model design?
Thanks for reading!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
缓存不应在域级别定义，而应在存储库实现级别定义（因此在 DAL 中）。例如，
ICountryRepository在 DAL 中应该有两个实现：CountryRepository 和 ChachedCountryRepository。这些应该在 Unity 中连接为装饰器（CountryRepository位于ChachedCountryRepository内部）。CachedCountryRepository将检查数据是否在缓存中，如果不在，则会将调用传递给内部CountryRepository。创建对象并不昂贵，并且不会太关心问题，因为缓存已正确定义。
The cache shouldn't be definied on the domain level but on the repositories implemntation level (so in DAL). So for example
ICountryRepositoryshould have two implementations in DAL : CountryRepository and ChachedCountryRepository. These should be wired as decorators in Unity (CountryRepositoryis inside theChachedCountryRepository).CachedCountryRepositorywould check if the data is in the cache and if not it would pass the call to the innerCountryRepository.Creating objects is not expensive and wouldn't care too much about issues as a caching is correctly definied.
伟大的推理。
然而，创建对象的成本很低。我不会创建单例，因为您已经在静态字段中缓存了所有对象。当前的方法很容易理解。
我还有一个问题要问你：
为什么不在存储库类中进行缓存？
存储库负责数据，所有数据处理都应该对其他一切透明。它还使一切变得更容易，因为他们负责更新数据源。如何使缓存与当前的更改保持同步？通过领域事件？
我将创建一个缓存类，将其用作存储库中的私有字段。
Great reasoning.
However, creating objects is cheap. I would not create a singleton since you already are caching all objects in static fields. The current approach is easy to understand.
I got another question for you:
Why are you not caching in your repository classes?
The repositories are responsible for the data and all data handling should be transparent to everything else. It also makes everything easier since they are responsible of updating the data sources. How do you keep the cache in sync with changes today? Through domain events?
I would create a cache class which I would use as a private field in the repository.