为什么不把数据访问层分成两层呢？
无论我看什么，我都注意到领域驱动设计（DDD）和实体水合方法都试图直接从数据层填充实体。我不同意这样的做法。这并不是因为这些方法不起作用，而是因为它们确实有效。相反，我认为这种方法对于测试目的来说透明度较低。我建议在数据访问层检索数据以填充字典，而不是直接填充实体本身。原因有几个：
第一，灵活性更大。可以填充每个结果集的字典。我们稍后将决定可以从这些结果集中填充哪些实体。
其次，需要较少的数据层知识来确定数据检索失败的位置。我们仍然可以编写测试来验证数据检索，而不必了解其关联的复杂域实体工厂的任何信息。
有一个所谓的缺点，性能？经过两层比经过一层慢？是的，确实如此，但是通过单个数据层获得的性能增益在这里可以忽略不计。我这么说的原因是因为字典和这些字典将填充的条目都会被缓存。所以，如果有的话，就会有内存开销。我认为，为了获得上述两个优势，这是值得的。
Everywhere I look, I noticed that both Domain Driven Design (DDD) and entity hydration approaches attempt to populate entities directly from the data layer. I disagree with such approaches. It is not because these approaches do not work because these do. Instead, I would argue that such approaches give a low level of transparency for testing purposes. I propose that at the data access layer, data is retrieved to populate dictionaries instead of the directly populating the entities themselves. There are several reasons for this:
First, there is greater flexibility. A dictionary per result set could be populated. We would decide later which entities could be populated from these result sets.
Second, less knowledge about the data layer is needed to determine where data retrival is failing. We may still write tests for verify data retrieval without having to understand anything about its associated complex domain entity factories.
There is one so-called disadvantage, performance? Going through two layers is slower than going through one? Yes, it is but the performance gain from going through a single data layer is negliable here. The reason I say this is because both the dictionaries and the entries these dictionaries would populate would be cached. So, if anything there would be a memory overhead. I think this would be worthwhile to gain the two advantages stated above.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
看来测试是问题所在（“出于测试目的”），所以我建议您使用 存储库就像@tschmuck 指出的那样。
正如 Ayende 指出的，它们可能会给你不必要的烤宽面条代码（即太多层），但它们会给你灵活性。您可以自己实现假冒/测试间谍、模拟和存根，以及使用内存数据库（例如 SQLite），并且依赖类也同样高兴。
It seems like testing is the issue ("for testing purposes"), so I suggest you use repositories just like @tschmuck pointed out.
As Ayende points out, they might give you unnecessary lasagna code (i.e. too many layers), but they will give you flexibility. You can implement fakes/test spies yourself, mock and stub 'em, as well as use an in-memory DB such as SQLite, and the dependent class is just as happy.