Zend 框架中的建模
我目前正在开发一个大型项目，只是想知道哪种最佳实践是分别对实体和实体集建模还是在一个类中建模？
目前，我正在为每个实体实现两个类（例如“作者”和“作者”类），其中复数类包含“获取作者”等方法（使用 Zend_Db_Table_Abstract 表示复数，使用 Zend_Db_Table_Row_Abstract 表示单数）。
然而，我意识到我经常在单个实体的对象中看到诸如“获取/列表”函数之类的方法，这看起来非常简洁，因为我不必拥有那么多文件。
我知道数据建模没有硬性规定，但在继续深入之前，我有兴趣了解最佳实践的普遍共识是什么（当然还有支持论据！）。
答复[意见]感激不尽！
罗布·甘利
I'm working on a large project at the moment and am just wondering which is best practice, to model entities and sets of entities seperately or in one class?
Currently I am implementing two classes for each entity (for example an 'author' and 'authors' class) where the plural class contains methods like 'fetch authors' (using Zend_Db_Table_Abstract for plural and Zend_Db_Table_Row_Abstract for singular).
However I realised that I've often seen methods like 'fetch/list' functions in a single entity's object, which seems quite neat in terms of the fact that I won't have to have as many files.
I know there are no hard-and-fast rules for data modelling but before I continue too far I'd be interested in learning what the general consensus on best-practice for this is (along with supporting arguments of course!).
Answers [opinions] gratefully received!
Rob Ganly
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
就我个人而言，我更喜欢使用名为
Person的模型来实际表示单个人，并使用名为PersonCollection的模型来表示人员的集合。在这两种情况下，我都没有获取/获取这些对象的方法。相反，我会将这些方法放在PersonRepository或PersonMapper类上。这确实是我对 ActiveRecord 作为建模模式最不满意的地方。通过使用
find()和save()等方法，它为getPersonByName()、getPersonsWithMinimumAge() 等方法打开了大门这些方法很棒，没有任何问题，但我认为从语义上讲，它们在映射器或存储库类上工作得更好。让Model实际建模，将持久性和检索留给映射器和存储库。因此，为了更直接地解决您的问题，我看到每个“实体类型”可能有三个类：
Person- 实际上模拟一个人PersonCollection- 扩展一些抽象集合类，每个项目类 PersonPersonMapper-Person对象和PersonCollections的持久化和检索控制器将使用映射器来持久化和检索模型和集合。
我被 Doctrine2 所吸引可能并不奇怪。 EntityManager 充当持久性和检索的单点联系。然后，我可以创建使用 EntityManager 实现自定义功能的存储库和服务。然后，我可以在操作助手或工厂或依赖项注入容器上分层，以便轻松获取/创建这些存储库和服务。
但我知道标准的 ActiveRecord 方法非常常见、易于理解并且非常主流。使用它可以获得良好的结果，并且可以找到许多立即理解它并可以很好地使用它的开发人员。
就像大多数事情一样，YMMV。
Personally, I prefer a model called
Personto actually represent a single person and a model likePersonCollectionto represent a collection of persons. In neither case, would I have methods for fetch/get on these objects. Rather, I would put those methods on aPersonRepositoryor aPersonMapperclass.That's really my biggest area of discomfort with ActiveRecord as a pattern for modeling. By having methods like
find()andsave(), it opens the door to methods likegetPersonByName(),getPersonsWithMinimumAge(), etc. These methods are great, nothing wrong with them, but I think that semantically, they work better on a mapper or a repository class. Let theModelactually model, leave persistence and retrieval to mappers and repositories.So, to more directly address your question, I see potentially three classes per "entity type":
Person- actually models a personPersonCollection- extends some Abstract Collection class, each item of class PersonPersonMapper- persistence and retrieval ofPersonobjects andPersonCollectionsControllers would use the mapper to persist and retrieve models and collections.
It's probably no surprise that I'm drawn to Doctrine2. The
EntityManagerthere functions as a single point of contact for persistence and retrieval. I can then create repositories and services that use theEntityManagerfor custom functionality. And I can then layer on action helpers or factories or dependency injection containers to make it easy to get/create those repositories and services.But I know that the standard ActiveRecord approach is quite common, well-understood, and very mainstream. You can get good results using it and can find many developers who immediately understand it and can work well with it.
As in most things, YMMV.