您将如何编写像“工厂”这样的存储库模式？ 设计模式？
我想我会重写这个问题（相同的迭代）。 最初是如何围绕 EAV/CR 数据库包装存储库模式。 我正在尝试一种不同的方法。
问题：如何以“工厂”设计模式方式编码数据存储库？我有固定数量的实体，但这些实体的属性是相当特定于客户的。 他们宣传的产品都是相似的，但每个客户根据他们的商业模式附加不同的信息。 例如，有些人关心浪费的百分比，而另一些人则关心销售的磅数。 每次我们找到另一个客户时，我们都会添加一堆字段，删除一堆字段，然后花几个小时让每个解决方案保持最新的通用版本。
我认为我们可以将存储库类放入工厂模式中，这样当我知道客户类型时，我就知道他们会使用哪些字段。 实际的？ 更好的方法？ Web 表单使用用户控件，这些控件经过修改以反映布局上的字段。 目前，我们将布局上找到的字段“联接”到产品表中找到的字段，然后是 CRUD 公共字段。
上一个问题内容：
我们有一个 EAV/CR 数据模型，允许同一实体使用不同的类。 这会跟踪客户拥有截然不同的产品的产品。 客户可以定义产品“类”，加载字段，然后填充数据。 例如，
Product.Text_Fields.NameProduct.Text_Fields.VitaminEContent
关于如何围绕此包装存储库模式有什么建议吗？
我们有一个三表 EAV：一个 Product 表、一个值表和一个列出字段名称和数据类型的元表（我们列出数据类型是因为我们还有其他表，如 Product.Price 和 Product.Price 元数据） ）客户可以跟踪各种价格，例如竞争对手的折扣差异以及即时计算。
目前，我们将 Linq to SQL 与 C# 结合使用。
编辑：
我喜欢下面的“动态查询”Linq。 我们数据库背后的想法就像更衣室的储物柜。 每个运动员（或顾客）都按照自己的意愿整理自己的储物柜，我们负责为他们存放。 我们不在乎储物柜里有什么，只要他们能用它做他们需要做的事情。
非常有趣...传递到存储库的对象可以是动态的？ 这几乎是有道理的，几乎就像工厂模式一样。 客户是否可以将自己的类定义放在一个文本文件中，然后我们继承它们并将它们存储在数据库中？
I thought I would rewrite this question (same iteration). The original was how to wrap a repository pattern around an EAV/CR database. I am trying a different approach.
Question: How could you code a data repository in a "factory" design pattern way? I have a fixed number of entities, but the attributes to these entities are fairly customer specific. They advertise Products which are all similar, but each customer attaches different information to them based on their business model. For example, some care about the percent slab off waste while others care about the quantity of pounds sold. Every time we find another customer, we add a bunch of fields, remove a bunch of fields, and then spend hours keeping each solution current to the latest common release.
I thought we could put the repository classes in a factory pattern, so that when I know the customer type, then I know what fields they would use. Practical? Better way? The web forms use User Controls which are modified to reflect what fields are on the layouts. We currently "join" the fields found on the layout to the fields found in the product table, then CRUD common fields.
Previous question content:
We have an EAV/CR data model that allows different classes for the same entity. This tracks products where customers have wildly different products. Customers can define a "class" of product, load it up with fields, then populate it with data. For example,
Product.Text_Fields.NameProduct.Text_Fields.VitaminEContent
Any suggestion on how to wrap a repository pattern around this?
We have a three table EAV: a Product table, a value table, and a meta table that lists the field names and data types (we list the data types because we have other tables like Product.Price and Product.Price Meta data, along with others like Product.Photo.) Customers track all kinds of prices like a competitor's percent off difference as well as on the fly calculations.
We currently use Linq to SQL with C#.
Edit:
I like the "Dynamic Query" Linq below. The idea behind our DB is like a locker room locker storage. Each athlete (or customer) organizes their own locker in the way they wish, and we handle storing it for them. We don't care what's in the locker as long as they can do what they need with it.
Very interesting... The objects passed to the repository could be dynamic? This almost makes sense, almost like a factory pattern. Would it be possible for the customer to put their own class definitions in a text file, then we inherit them and store them in the DB?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
据我了解，存储库模式从应用程序中抽象出数据库的物理实现。 您打算将数据存储在不同的数据存储中吗？ 如果您对 Linq to SQL 感到满意，那么我建议您也许不需要以这种方式进行抽象，因为它看起来非常复杂。 也就是说，我可以看到，提供 EAV 风格的存储库（即查询需要传递表、字段类型和字段名称以及任何所需的条件）可能会为您提供您正在寻求的抽象。
我不确定从最严格的角度来看这是否仍然符合存储库模式的资格，因为您并没有真正从应用程序中抽象存储。 这将是利益和努力之间的抉择，而我无能为力。
您可能想要查看在 Codeplex 上的动态数据预览中找到的 Dynamic Linq 扩展。
As I understand it the repository pattern abstracts the physical implementation of the database from the application. Are you planning to store the data in differing data stores? If you are happy with Linq to SQL then I'd suggest that perhaps you don't need to abstract in this way as it looks to be extremely complex. That said, I can see that providing an EAV-style repository, i.e. a query would need to be passed Table, Field Type, and Field Name along with any conditional required, might offer you the abstraction you are seeking.
I'm not sure if that would still qualify as a repository pattern in the strictest terms as you aren't really abstracting the storage from the application. It's going to be a toss-up between benefit and effort and there I'm unable to help.
You might want to take a look at the Dynamic Linq extensions found in the dynamic data preview on Codeplex.