如何处理域和数据库层之间的通信？ [英] How To Handle Communication Between the Domain and Database Layers?
问题描述
澄清我现有的解决方案使用数据映射来直接处理数据库交互。然而，由于我进一步调查了这个问题，许多人建议域层不应该直接与之通信，也不应该包含实际执行数据库交互的数据映射器。这就是为什么我将Repository对象放在Domain和必要的数据映射器之间，但这并不是很自然或正确。所以真正的问题是什么层自然存在来处理域和数据映射器之间的通信？
例如：
- 如何正确处理在另一个域对象的上下文中检索域对象的集合？
- 如何强制根据操作插入单个域对象或对象集合对另一个对象执行。目前我遇到的情况是，当一个人附加到一个广告系列时，我需要插入该广告系列需要为该人员执行的所有活动。
Gabriel，这被称为阻抗匹配问题。有许多解决方案，从重量级的J2EE实体bean到Ruby ActiveRecord，只需编写一个手动连接。
更新
好的，很难看出如何攻击这个没有更多的信息，但这是基本的方法。
这些架构问题中的任何一种都是由非功能性要求（如性能）驱动的。另外，这里有一个正确的问题，因为你想确保更新按正确的顺序完成。所以，您将需要考虑工作负载，这就是说现实世界应用程序中的使用模式。考虑到这一点，您基本上有几个问题：首先，应用程序中的基本数据类型可能无法正确映射到数据库（例如，代码中表示的VARCHAR属性是什么？），第二个域模型可能无法清晰地映射到您的数据库模型。
您想要的是让数据库和dmain模型工作，使一个域对象的一个实例完全是你的数据库模型中的一行表;在大规模应用程序中，由于性能限制或预先存在的数据库模型所施加的约束，您很少会这样做。
现在，如果您完全控制数据库模型它简化了一些事情，因为这样可以使您的数据库模型更接近于域。这可能意味着数据库模型有些非规范化，但是如果是这样，您可以（取决于您的数据库）使用视图处理该数据库，或者没有完全规范的数据库。规范化是一个有用的理论结构，但这并不意味着你无法在真正的系统中放松。
如果你不要完全控制你的数据库模型，然后你需要一层对象来做映射。您可以从实现中选择一些选项：您可以在数据库中构建视图或非规范化表，您可以构建中间对象，或者您可以进行一些操作，或者甚至可以同时执行两个步骤（即，一个访问非正规表的中间对象。）
然而，在这一点上，你遇到了不要重复自己和做最简单的事情可能会工作。想想最有可能改变什么？您的域名模型？如果您拥有强大的域名模式，那么可能性就会降低 - 业务变化相对较少。数据库中数据的准确表示方式？一点更常见或者，最常见的是使用的确切模式（如发现需要处理并发更新）。所以，当你想到这一点，你需要做什么来使它尽可能容易地处理最常见的变化。
我意识到这不是给你非常精确的指示，但我不认为我们可以提供精确的指示，而不必了解你的应用程序。但是，我也有一种让人印象深刻的是，您正在处理这种情况的正确方式，而您已经在做或多或少的工作。所以，最后我会问：你现在不开心什么？和你想如何解决？
I am fairly new to using separate layers for the business logic (Domain) and database access logic, but in the course of working things out I've come across a problem to which I still feel I haven't found a great solution.
Clarification My existing solution uses Data Mappers to deal with the database interactions directly. However, as I've further investigated this issue many people have suggested that the Domain layer should not directly communicate with nor contain the Data Mappers that actually perform the database interaction. This is why I placed the Repository objects between the Domain and the necessary Data Mappers but this doesn't feel quite natural or correct. So the real question is what layer naturally exists to handle communication between the Domain and the Data Mappers? Any examples of how to structure it would be appreciated.
For example:
- How do I properly handle retrieving a collection of domain objects within the context of another domain object?
- How do I force the insertion of a single domain object or collection of objects based on an action performed against another object. The case I'm facing currently is that when a Person is attached to a Campaign, then I need to insert all of the Events that need to be executed for that Person for that Campaign.
Gabriel, this is called the "impedance matching problem." There are many solutions around, from heavyweight ones like J2EE entity beans to Ruby ActiveRecord to simply coding a hand connection.
Update
Okay, well, its hard to see exactly how to attack this without a lot more information, but here's the basic approach.
Any of these sorts of architectural issues are driven by non-functional requirements like performance; in addition, there is a correctness issue here, in that you want to make sure updates are done in the correct order. So, you're going to need to think about the workload, which is to say the pattern of usage in real-world application. With that in mind, you basically have a couple of issues: first, the base data types in your application may not map correctly to the data base (eg, what's a VARCHAR property represented as in your code?), and second your domain model may not map cleanly to your database model.
What you would like is to have the database and the dmain model work out so that one instance of a domain object is exactly a row of a table in your database model; in large-scale applications you can rarely do this because of either performance constraints or constraints imposed by a pre-existing database model.
Now, if you completely control your database model, it simplifies things somewhat, because then you can make your database model more closely resemble the domain. This might mean the database model is somewhat denormalized, but if so, you can (depending on your database) handle that with views, or just not have a completely normalized database. Normalization is a useful theoretical construct, but that doesn't mean you can't relax it in a real system.
If you don't completely control your database model, then you need a layer of objects that make the mapping. You've got a bunch of options to choose from in implementing that: you can build views or denormalized tables in the database, you can build intermediate objects, or you can do some of both, or even have several steps of both (ie, an intermediate object that accesses a denormalizaed table.)
At that point, though, you run into issues with "don't repeat yourself" and "do the simplest thing that will possibly work." Think about what is most likely to change? Your domain model? If you've got a strong domain model, that's less likely --- the business changes relatively rarely. The exact representation of data in the database? A little more common. Or, most commonly, the exact patterns of use (like discovering a need to handle concurrent updates.) So, when you think about that, what do you need to do to make it as easy as possible to deal with the most common changes.
I realize this isn't giving you very precise instructions, but I don't think we can offer precise instructions without knowing a whole lot about your applicaiton. But then I also kind of get the impression you're wondering about what the "right" way of handling this would be, while you are already working with something that more or less does the job. So, I'd end up by asking "what are you unhappy with now?" and "How would you like to solve that?"
这篇关于如何处理域和数据库层之间的通信？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
