领域驱动设计中检索对象集合的方法
我正在使用 Zend Framework,并尝试转向 DDD 方法(领域驱动设计)。我有域对象的模型、映射器和 DbTable。
在很多情况下,我需要同时获取多个实体,例如-系统内所有用户的列表-,因此我的用户模型将有一个方法“getAllUsers”,它将返回所有用户(现在它返回一个所有用户的数组,但我正在考虑制作一个集合类)。到目前为止,我正在使用普通方法(非静态)来获取集合,为此,我需要创建一个“空”对象。另一种选择是将其转换为静态方法。
我不确定哪种方法更好,将此类方法保留为非静态方法或将它们转换为静态方法。更好的方法/实践是什么?为什么?哪种方法也紧密遵循 DDD 方法。
PS:如果您能想到更好的标题,请告诉我。不,这不是一个课程问题。
I am using Zend Framework and also try to move towards DDD approach (Domain-Driven Design). I have models, mappers and DbTables for domain objects.
There are many situations when I need to fetch multiple entities of same time, for example -list of all users within the system-, so my user model will have a method 'getAllUsers' which will return all the users (right now its returning an array of all the users, but I am thinking of making a collection class). So far I am using a normal method (non-static) to fetch the collection, and for this purpose, I need to create an 'empty' object. The other option is to convert it into a static method.
I am not sure, which approach is better, keep such methods as non-static or convert them into static methods. And what is the better approach/practice and why? Also which approach closely follow the DDD methodology.
PS: Kindly let me know, if you can think of a better title. And NO its not a course question.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
首先,我认为这不是 DDD 相关的问题。使用或不使用静态方法更像是OOP或设计问题。
基本上,使用类静态方法并不是真正的 OOP,而是过程编程,因为您不能使用任何 OOP 范例,例如封装或继承。它指出了可能的设计缺陷/代码味道。
它还使单元测试变得困难,因为模拟静态 方法更加复杂,据我所知,添加它只是为了允许通过单元测试覆盖遗留代码。
如果发布一些代码示例,那么回答您的问题会更容易。
此处回答了类似的问题, 此处 或此处。
Firstly, I think this is not DDD related question. To use or not static methods is more like OOP or designing question.
Basically using class static methods is not really OOP but procedural programming because you cannot use any of the OOP paradigms like encapsulation or inheritance. It points at possible design flaws/code smell.
It also makes the unit testing hard, because mocking of static methods is more complicated and AFAIK it has been added just to allow covering the legacy code by unit tests.
It would be easier though to answer your question if posted some code examples.
Similar questions were answered here, here or here.
静态方法意味着不需要实例化对象来调用它。通常,静态方法用于对与整个类相关而不仅仅是类的特定实例相关的方法进行分组。相反,非静态方法用于对与特定单个对象相关的方法进行分组。
因此,如果您将 getAllUsers() 标记为非静态并将其放在 user 之下,基本上您是在要求一个特定用户了解所有其他用户。打个比方——这就像向一个公民询问有关该国所有公民的完整信息(您知道您所在国家/地区的所有人吗?)。
将其标记为静态就像从百科全书中的公民定义询问有关所有公民的信息。这比将其标记为非静态要好,但仍然有点奇怪和尴尬。
通常,国家都有人口登记册,负责处理有关公民的信息。转换回类比 - 你会有“其他东西”,类似集合的寄存器来负责这个。
Static method means that there is no need for instantiated object to call it. Usually static methods are used to group methods that are related to whole class not just particular instance of class. In contrast - non static methods are used to group methods that are related to particular individual object.
So, if you are marking getAllUsers() non-static and put it underneath user, basically you are asking for one particular user to know about every other user. Using analogy - that would be like asking full information about all citizens in country from one individual citizen (do you know them all in your country?).
Marking it static would be like asking for information about all citizens from citizen definition in encyclopedia. It's better than marking it non-static, but still a bit strange and awkward.
Normally countries have population registers that are responsible for dealing out information about citizens. Converting analogy back - you would have "something else", collection-like register that is responsible for this.
在领域驱动设计中,持久的用户集合应表示为 UserRepository 接口。该接口的具体实现具有状态,包括例如数据库连接的状态。因此,您需要一个存储库实现的实例,并且它的方法将是实例方法而不是静态方法。
In Domain Driven Design, a persistent collection of users should be represented as a
UserRepository
interface. The concrete implementation of that interface has a state, including for example the state of the database connection. So it follows that you need an instance of the repository implementation, and its methods would be instance methods rather than static methods.