在业务层中过滤来自数据访问层的结果
到目前为止我还没有找到我的问题的答案，我想我必须找个时间问我的第一个问题。就这样吧。
我有一个数据访问层，负责与各种数据存储元素交互，并在查询时返回 POCO 或 POCO 集合。
我有一个业务层位于其之上，负责对从数据访问层返回的对象实施业务规则。
例如，我有一个狗的 SQL 表，我的数据访问层可以将该狗列表作为 Dog 对象的集合返回。然后，我的业务层将执行诸如过滤掉特定年龄以下的狗之类的操作，或者必须根据业务规则进行的任何其他过滤或转换。
我的问题是这样的。根据相关记录处理过滤对象的最佳方法是什么？假设我想要所有养猫的人。现在我的数据访问层可以返回所有的猫和所有的人，但它不会为我做任何过滤。
我可以通过不同的数据访问方法（即 DAO.GetCatPeople()）实现过滤，但是如果我有大量相关属性或关系需要处理，这可能会变得复杂
我可以从双方返回所有内容并自己进行匹配业务层，这似乎有很多额外的工作并且没有充分利用 SQL Server。
我可以写一个数据过滤接口；如果我的数据访问层发生变化，该层也必须发生变化。
这里有一些我可以受益的已知最佳实践吗？
I haven't been able to find an answer to my question so far, and I suppose I have to ask my first question sometime. Here goes.
I have a Data Access Layer responsible for interacting with various data storage elements and returns POCOs or collections of POCOs when querying things.
I have a Business Layer that sits on top of this and is responsible for implementing business rules on objects returned from the Data Access Layer.
For instance, I have an SQL Table of Dogs, my data access layer can return that list of dogs as a collection of Dog objects. My business layer then would do things like filter out dogs below a certain age, or any other filtering or transformation that had to happen based on business rules.
My question is this. What's the best way to handle filtering objects based on related records? Let's say I want all the people who have Cats. Right now my data access layer can return all the cats, and all the people, but it doesn't do any filtering for me.
I can implement the filtering via a different data access method (i.e. DAO.GetCatPeople()) but this could get complicated if I have a multitude of related properties or relationships to handle
I can return all from both sides and do the matching myself all in the business layer, which seems like a lot of extra work and not fully utilizing the SQL server.
I can write a data filtration interface; if my data access layer changes, this layer would have to change as well.
Are there some known best practices here I could be benefiting from?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我的观点是，访问数据有两个“原因”：以数据为中心和以用例为中心。
我认为这两种类型都是有效的。对于用例驱动的用例，它将主要由以业务为中心的用例驱动，但我可以看到它们可以更加技术驱动的边缘情况 - 我想说只要它们不违反任何业务规则就可以或者破坏你的领域模型。
猫和狗应该互相了解吗？如果它们存在于同一域模型中，并且在该模型中建立了关系 - 那么当然您应该能够进行像
GetCatPeople()这样的查询。就管理复杂性而言，您可以使用一个更通用的方法，将属性作为参数，而不是
GetCatPeople()：GetPeopleByAnimal(animal)。The view I take is that there's two "reasons" why you'd access data: Data centric and Use Case centric.
I think both types are valid. For the use case driven ones it's going to be mostly driven by business focused use cases, but I can see edge cases where they could be more technically driven - I'd say that was ok as long as they didn't violate any business rules or pervert your domain model.
Should Cats and Dogs know about each other? If they exist within the same domain model, and have established relationships within that model - then yes of course you should be able to make queries like
GetCatPeople().As far as managing the complexity goes, rather than
GetCatPeople()you could have a more generic method that took an attribute as a parameter:GetPeopleByAnimal(animal).