与存储库模式的关注点分离
我有一个关于存储库访问位置的问题。允许或包含存储库维护的实体内的存储库访问是否可以接受？
例如：
class Product
{
public int ProductID {get;set;}
public int Name {get;set;}
public IList<Product> Products {get;set;} // A Product may be a bulk item that contains several individual items.
public int VendorID {get;set;} // Key to another table that list vendor info.
}
public class ProductRepository : IRepository
{
public Product GetProduct(int id) {}
public IList<Product> GetProducts() {}
}
几个问题：
- 从其他表中检索信息应该位于哪里？存储库、服务、实体等。这是否也适用于散装物品的包含产品？
- 这种情况应该何时发生，在检索产品时，或者是否/当访问供应商/子产品时？
I have a question regarding location of repository access. Is it acceptable practice to allow or contain Repository access within an Entity that the Repository Maintains?
For example:
class Product
{
public int ProductID {get;set;}
public int Name {get;set;}
public IList<Product> Products {get;set;} // A Product may be a bulk item that contains several individual items.
public int VendorID {get;set;} // Key to another table that list vendor info.
}
public class ProductRepository : IRepository
{
public Product GetProduct(int id) {}
public IList<Product> GetProducts() {}
}
A Few Questions:
- Where should retrieval of information from other tables be located? Repository, Services, Entity etc.. Would this also apply to the Contained Products for bulk Items?
- When should this occur, At the time the product is retrieved, or if/when the Vendor/SubProduct accessed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我建议研究 ORM（对象关系映射器）处理此类问题的方式；一般来说，他们处理的方式是存储库根据需要管理所有序列化/反序列化；有一些相对复杂的逻辑用于反序列化树中的元素（延迟加载等）。 ORM 领域已经考虑了许多此类问题，并且有一些解决方案考虑了每个潜在解决方案的彻底细节，因此这是合适的地方。作为起点，请考虑研究 Hibernate 如何发挥其魔力；它是一种广泛使用的 ORM，具有非常好的设计。
特别是，我强烈建议不要尝试自己实现此类内容；考虑使用 ORM（我和其他人再次高度推荐 Hibernate）来处理此过程的具体细节；他们已经解决了做这件事时出现的许多问题。
I'd recommend looking into the way ORMs (Object Relational Mappers) handle this sort of issue; in general, the way they handle it is that the repository manages all serialization / deserialziation as needed; there's some relatively complex logic that goes on for deserializing the elements in a tree (lazy-loading and the like). The ORM space has considered many of these issues, and there are solutions that consider the thorough ins and outs of each of the potential solutions, so that's the appropriate place to look. As a starting point, consider looking into how Hibernate does its magic; it's a widely used ORM that has a pretty good design.
In particular, I'd strongly advise against trying to implement this sort of stuff yourself; look into using an ORM (again, Hibernate comes highly recommeded, from me and from others) to handle the specifics of this process; they've worked through many of the issues that come up in doing this stuff.