将两个相关对象的业务逻辑放在哪里?
假设我有两个实体:User
和 UserGroup
。
他们有一对多的关系 =>每个UserGroup
实际上包含0到n个用户。
如果我想检索 UserGroup
的用户,在业务层的哪个类中放置该方法会更好?
- 在
UserManager
中添加方法:GetAllUsersForUserGroup
- 在
UserGroupManager
中添加上述方法。
猜想2更好。但我不确定。
谢谢。
更新
我想我无法完全解释我的意思。
是的,我们可以有 User
、Users
、Group
、Groups
等。
但我不想找到可以应用哪些不同的模式等来实施业务。我的问题是:您将 GetAllUsersForUserGroup(int UserGroupID)
放入 UserManager
还是 GroupManager
中?您认为 GetAllUsersForUserGroup(int UserGroupID)
应该定义在管理用户的类中还是管理用户组的类中?
Suppose I have two entities: User
and UserGroup
.
They have a one-to-many relationship => each UserGroup
virtually contains 0 to n number of users.
If I want to retrieve the users for a UserGroup
where in my business layer would be a better class to put that method?
- In
UserManager
, add method:GetAllUsersForUserGroup
- in
UserGroupManager
add the above method.
Guess 2 is better. But I'm not sure.
Thanks.
UPDATE
Guess I couldn't completely explain what I meant.
Yes we can have User
, Users
, Group
, Groups
, etc.
But I'm not trying to find out what different patterns, etc can be applied to implement the business. my question is: do you put GetAllUsersForUserGroup(int UserGroupID)
in UserManager
or in GroupManager
? Do you think GetAllUsersForUserGroup(int UserGroupID)
should be defined in a class that is managing users or in a class that's managing user groups?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
当然,如果不确切了解管理者和管理者的客户的结构以及他们已经提供的方法,就很难发表意见。
假设管理器是简单的 DAO,具有用于基本实体操作的 CRUD 操作,我会考虑使用更高级别的 UserRepository 或 UserService 对象来提供更多类似“业务”的功能,例如
IList。 FindUsersByGroup( UserGroup group );
总之,没有正确的答案,从逻辑上讲,您可以以任何一种方式争论 - 我的决定基于使管理器尽可能简单,避免对象膨胀,关注如何您会看到应用程序在不久的将来不断发展,并在必要时进行重构,它的可维护性将成为一个问题。
Of course it's difficult to give an opinion without knowing exactly how the managers and the clients of the managers are structured and what methods they already offer.
Assuming the managers are simple DAOs with CRUD operations for the basic entity operations I'd think about having a higher level UserRepository or UserService object providing more 'business' like functions such as an
IList<User> FindUsersByGroup( UserGroup group );
In summary though, there's no right answer as logically you could argue either way - I'd base my decision on keeping the managers as simple as possible, avoid object bloat, keep an eye on how you see the application evolving in the near future and refactor if necessary it maintainability becomes an issue.
您还可以使用工厂模式。
例如:
如果用户组表有用户和组 ID,我将其放入 UserGroup 工厂中。
You could also use a Factory Pattern.
eg:
If the User Group table has the user, and group ID's I put put it in the UserGroup factory.
正如@Tom Carter 所说,很难准确地找出最适合您的答案,因为缺少很多细节。我认为大多数“管理器”类实际上可以使用良好的 OOP 来删除。
您的 UserGroup 类可能看起来像这样:
这有助于构建丰富的对象并将业务逻辑保留在对象内部,并使您不必求助于创建一堆“Manager”类。
As @Tom Carter said, it's hard to figure out exactly the best answer for you because there are a lot of details missing. I think that most "manager" classes can actually be removed using good OOP.
Your UserGroup class could then look something like this:
This helps build a rich object and keeps the business logic inside of your objects and keeps you from having to resort to creating a bunch of "Manager" classes.
此方法应在
UserManager
/UserRepository
类中定义。Manager
/Repository
类通常设计为具有一组类似的方法来处理具体类的对象,例如User
code> 类。这些方法包括根据某种规范从数据库/缓存/本地集合创建/请求/检索该类的一个或多个对象的方法。
按
UserGroup
规范Get
Users
的方法就是其中一种方法。如果所有用户都存储在组内,
或者如果所有用户都存储在一个集合内,则最简单的实现:
This method should be defined in a
UserManager
/UserRepository
class.A
Manager
/Repository
class is usually designed to have a set of similar methods to work with objects of a concrete class, for example aUser
class.These methods include methods to Create / Request / Retrieve from Database / Cache / Local collection one or more objects of the class by some specification.
A method to
Get
Users
byUserGroup
specification is one of there methods.The most simple implementation if all users are stored inside the group:
or if all users are stored inside one collection:
如果您获取用户列表,我会将该方法放在 Users 类中,因此它读起来很自然,例如:
If you Getting a list of Users, I would put the method in the Users class, so it reads naturally, like: