如何实现DDD存储库来处理与倍数实体的查询？ [英] how to implement DDD repository to handle a query with multiples entities?

问题描述

我在努力实现.NET解决方案采用DDD的要求。我会尽量减少细节：

I'm struggling to implement a requirement using DDD in a .net solution. I'll try to minimize the details:

实体：

• 在类别（UID，名称）
• 属性（UID，名称，AttributeValues​​ []）
• 的AttributeValue（UID，名称，ParentAttributeUId）
• 工艺（UID，名称，AttributeValues​​ []，分类[]）

数据模型：

• 在每一个进程可以有多个类别（如ProcessCategoryMap表）
• 在每一个进程可以有多个AttributeValues​​（如ProcessAttributeValue表）
• 类没有关系，属性，attributeValues​​

我有一个S.P. FetchByCategoryAndAttributeValues​​（的CategoryId，AttributeValueIds []） 返回一个数据集：

I have a s.p. FetchByCategoryAndAttributeValues(CategoryId, AttributeValueIds []) Returns a DataSet:

• 进程相匹配的CategoryId名单和AttributeValueIds
• 可细化搜索AttributeValues​​列表。

如何实施库以及调用SP，当返回多个实体的方法，在我看来，返回的对象是一个值对象，似乎不是fiting中存在的实体仓库？

How to Implement the Repository plus the method to call the SP, when multiple entities are returned, it seems to me that the object returned is a value object and it seems not fiting in the existent entities repositories ?

任何想法？

问候，

佩德罗

====编辑：2011/03/30下午2时52 UTC ====

==== 2011/03/30 02:52 PM UTC ====

我更新我的问题，重视所有的意见以及帮助其他面临类似的挑战。

I'm updating my question, to value all the comments plus to help others facing similar challenges.

@Justice：

解决方案：使用ORM如NHibernate的加使用ORM的所有理由

solution: Use an ORM e.g. NHibernate plus all the justifications of using ORM

我不记得任何提及Eric Evans的DDD本书一个ORM的。如何做一个特定的持久化技术的选择在所有问题？一旦你的域名整理出来，你可以自由地坚持它，你希望的任何方式。 Offcourse我知道，NH帮助，是功能强大的工具，但它不是一个解决方案本身。

I don't recall any mention of an ORM in Eric Evans ddd book. How does the choice of a specific persistence technique matter at all ? Once you have the domain sorted out, you're free to persist it any way you wish. Offcourse i'm aware that NH can help and is powerful tool but it's not a solution per se.

@Dominic / @Justice：

@Dominic / @Justice:

解决方案：从存储过程的移开

Solution: Move away from Store Procedures.

首先，对我来说是困难的，当我看到好的T-SQL存储过程来证明​​，我不是在谈论CRUD或简单的T-SQL查询。列表分类列表流程，AttributeValues​​列表：我提的SP运行一些TSQL CTE，结合指标数据来自不同的表来计算权重，使用临时表，并返回客观结果。该SP进行了优化和调整为特定的SQL数据库/服务器可能是MSFT，Oracle等我不相信，转移这些计算的应用程序端，然后靠在ORM将有助于执行时间加都回来了并转发查询。对我来说，是拼尽全力，在服务器，只有使过滤后的数据有很大的区别。我可能是错的。

First of all, for me is difficult to justify when i see good T-SQL stored procedure, I'm not talking about CRUD or simple T-SQL Queries. The SP that i mention runs a few TSQL CTE, combine metric data from different tables to calculate the weights, using temporary tables and returns objective results : List Of Processes, List of Categories, List of AttributeValues. The SP is optimized and tuned for a specific SQL database/server could be an MSFT, Oracle, etc. I don't believe that transferring those calculations to the Application side, and then relying in the ORM would help the execution time plus all back and forward queries. For me there is a big difference of doing all that in server and bringing only the filtered data. I could be wrong.

@All： 我已经确定了真正的问题（如Domenic指出与ayende链接）我移植基于在数据中心的解决方案，以领域模型的方法解决。让我们把这一走，由SP返回的计算，会影响不同的型号。由于数据持久保存在数据库的方式，常见的有计算和计算实体之间为界，问题是，当移动到DDD的实现是如何得到最好的两个实现。以及如何让数据库管理员的工作:)

@All: I've identified the real problem (like Domenic point out with the ayende link) I'm porting a solution based in a Data Centric approach to a Domain Model approach. Let's put this away, the calculations returned by the SP, affects different Models. Due the way data are persisted in the DB, there are common calculations and calculations are bounded between the entities, the question is when moving to a DDD implementation is how to get best of both implementations. And also how to keep the DBAs jobs :)

您可以创建一个很好的领域模型，坚持跨越了N个不同的表中的数据，问题是，当你正在查询的数据如何把示范并保持DDD良好的立场。

You can create a very good Domain Model, persist the data spanning over N different tables, The question is when you are querying that data how to bring to the Model and keep the DDD in good stand.

感谢大家，我还在寻找的想法，答案等:)

Thank you all, I'm still looking for ideas, answers, etc :)

问候， 佩德罗

推荐答案

您当前的问题是如何将超过一个包含一些数据，并与一些无关的数据，它允许数据被进一步在一致的方式过滤的数据集以领域模型。

Your immediate problem is how to bring over a dataset that contains some data and and some "unrelated" data that allows that data to be filtered further in a fashion consistent with a domain model.

之所以说这是一个问题，因为这个概念 - 带过来的衍生或外围相关数据多表未与领域建模确实是一致的。领域建模的有关定义，纳入核心应用程序的基本领域知识的关系和复杂的业务逻辑。不从根本上得到相关的对象多表意味着它可能不是东西，是领域模型开始的一部分。

The reason why that is a problem is because the very concept - bring over multiple tables of derived or peripherally related data is not really consistent with domain modeling. Domain modeling is about defining the relationships and complex business logic that incorporate fundamental domain knowledge of the core application. Multiple tables that do not yield fundamentally related objects means it is probably not something that is part of the domain model to begin with.

如果你没有这些本质上适合你正在尝试做这意味着要么你的模型是不完整的，或者在这种情况下，可能你正试图泄露应用程序的用户界面方面到域模型哪些对象。也许是后者。

If you don't have objects which are inherently suited for what you are trying to do it means either your model is incomplete, or in this case possibly that you are attempting to leak user interface aspects of the application into the domain model. Probably the latter.

该解决方案还包括像MVP或MVC的用户界面视图结构。域对象是有关实施整个交易业务规则 - 保存和更新。使用的DTO和presenters例如组装任何种类的新或杂交不重新present芯领域知识而是将其构造为present数据到用户以某种方式的对象的用户想要。

The solution is to also include a user interface view architecture like MVP or MVC. Domain objects are about enforcing the business rules across transactions - saves and updates. Use DTOs and Presenters for example to assemble any sort of "new" or "hybrid" objects that do not represent core domain knowledge but are instead constructed to present the data to the user in some manner that the user wants.

在这种情况下，您只需创建一个DTO的整合过程和属性的DTO到一个新的对象在UI消费。

In this case you just create a DTO that incorporates the Process and Attribute DTOs into a new object for consumption in the UI.

但也有一些其他的可能性：

But there are some other possibilities:

1）有些时候，你要问自己，如果你甚至使用正确的工具来完成工作。我的工作，有一个非常复杂的域模型的医学应用。即核心应用 - 执行跨数据采集的过程复杂的规则。但是，一旦这些数据被收购的业务有兴趣做许多不同的事情吧。此次收购模型和分析模型是没有任何好处的配合，因此，而不是试图让他们一起工作，我觉得更好的选择有收购模式，即DDD，然后使用ETL和数据移动到数据仓库，给业务，是建立在查询一个单独的分析应用，而不是面向对象/ DDD。

1) There are times when you have to ask yourself if you are even using the right tool for the job. I am working on a medical application that has a very complex domain model. That is the core application - enforcing complex rules across the process of data acquisition. But once that data is acquired the business is interested in doing many different things with it. The acquisition model and the analytical model are not at all good fits, so instead of trying to make them work together I think the far better option to have the acquisition model which is DDD and then use ETL and move the data into a data warehouse and give the business a separate analytical application which is built on queries, not OOP/DDD.

2）领域建模的有关定义，反映了真实的域名，不是关系数据模型的技术。我们的目标是管理的复杂性，并创建一个模型，可以同时完善和发展的业务变化。你不会发现很多人在那里做了很多DDD那甚至会pretend的优化就是一个很好的方面。相反，你建立一个模型始终与DDD，你可能可以。如果您有以后你妥协的模式只之多，你必须为用户带来无法接受的性能到一个可接受的范围内。

2) Domain modeling is about defining models that reflect the true domain, not about relational data techniques. The objective is to manage complexity and create a model which can be both refined and evolved as the business changes. You will not find many people out there doing a lot of DDD that will even pretend that optimization is an aspect of that. To the contrary, you build a model as consistently with DDD as you possibly can. If you have to later you compromise that model only as much as you have to in order to bring unacceptable performance into an acceptable range.

有很多很多的事情可以说是更高效的查询操作。当然，如果有人不知道应用程序在所有他们可能要追溯了一堆的东西出来，很可能有或多或少的了解整个应用程序，才可以理解所有这一切。 DDD，你可以有工作的人对成功的东西时，他们知道基本上没有什么有关应用程序的其他部分，但你没有任何东西，甚至接近最优的性能或往返条款。

There are lots and lots of things you can do with queries that are much more efficient. Of course if someone does not know the application at all they may have to trace a bunch of that stuff out and quite possibly have to more or less understand the entire application before they can understand any of it all. DDD you can have people working on something successfully when they know basically nothing about the rest of the application, but you don't have anything even close to optimal in terms of performance or round trips.

由于有吸引力的和逻辑的，因为它似乎尝试两全其美的，我喜欢的ETL和数据仓库铁杆SQL的东西，而我呢DDD。我有些疑惑，如何成功的，你可以在一个应用程序合并这两个世界。两全其美的，而不是机会，你会落得一个应用程序，任何人都不能工作，不能很好地执行两种。如果你有一大堆的高效存储过程，也必然是一堆业务逻辑在里面。如果你也有有业务逻辑的对象，那么你最终与在数据库中的业务逻辑，在对象模型这原来只是业务逻辑（另一个）应用程序，有类，但不面向对象或DDD - pretty的同样的事情的人已经做了多年，并把它称为n层。

As attractive and logical as it seems to try for the best of both worlds, I do hardcore SQL stuff like ETL and data warehousing, and I do DDD. I have some doubts as to how successfully you can merge the two worlds in one application. Instead of the best of both worlds the chances are you will end up with an app no one can work with and does not perform well either. If you have a bunch of efficient stored procedures, there is bound to be a bunch of business logic in there. If you also have "objects" that have business logic then what you end up with is business logic in the database, business logic in the "object model" which turns out to be just (yet another) application that has classes, but is not OOP or DDD - pretty much the same thing people have already been doing for years and calling it "n-tier".

不要误会我的意思 - DDD的应用程序仍然应该建立在可靠的数据库和关系的原则并没有什么不妥的表现。但很多DB服务器的处理是泄漏到数据库的作用域中的活动。也有很多的优化数据处理这些技术违反了面向对象和DDD的多项原则。

Don't get me wrong - DDD apps should still be built on solid database and relational principles and there is nothing wrong with performance. But a lot of db server processing is in effect domain activity leaked to the databases. Also a lot of these techniques of optimal data handling violate multiple principles of OOP and DDD.

如果你不愿意彻底放弃所有的数据库的东西，而且它正在很好地帮助你，你可能不需要，甚至想搬到一个DDD的概念摆在首位。如果你想为DDD最好的办法是要考虑你的一切作为有价值的领域知识的来源，但在实施细节遗留code术语正在被彻底抛弃。 DDD是不是真的适合移植一个没有DDD的应用程序切换到。

If you are not willing to completely abandon all the database stuff, and it is working well for you, you may not need or even want to move to a DDD concept in the first place. If you want to DDD the best approach is to consider everything you have as a source of valuable domain knowledge but in terms of implementation details legacy code which is being completely abandoned. DDD is not really suitable for "porting" a none DDD app over to.

这篇关于如何实现DDD存储库来处理与倍数实体的查询？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！