为有时需要聚合其他对象但并非总是需要的对象设计 DataMapper
我有一个名为学生的对象，它映射到学生表。还有一个课程表和 user_courses 表用于将学生分配到课程。该学生对象可以有许多课程对象，因此，使用我的学生数据映射器，它将检索学生对象以及学生注册的课程的任何课程对象。这对于我需要所有这些信息的情况非常有效，但是在我只需要显示学生姓名的情况下，不需要检索课程对象。我的问题是，我应该如何设计我的 dataMappers 来解决这个问题？我是否应该为不同级别的学生对象提供单独的映射器，即仅包含基本学生信息的 baseStudentObject，然后是另外包含课程对象的 ExtendedStudentObject？或者更好地实现某种延迟加载解决方案？一如既往，我们非常感谢所有的意见！干杯。
I have an object called student which maps to a student table. There is also a courses table, and user_courses table to assign students to courses. This student object can have many course objects, and therefore, with my Students DataMapper it will retrieve student objects and any course objects for the courses that the student is enrolled in. This works fine for the cases where I need all of this information, but in the cases where I only need to display the student name and last name, the retrieval of course objects is unnecessary. My question is, how should I design my dataMappers to account for this? Should I have separate mappers for different levels of student objects, i.e. baseStudentObject with just the basic student info and then an extendedStudentObject which additionally includes the course objects? Or better to implement some sort of lazy loading solution? As always, all input is very much appreciated! Cheers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想说这是一个权衡。从设计角度来看，延迟加载路线将是最好的选择。您真的不希望人为地出现不同类型的学生，从而堵塞您的域模型。当然，如果您有一个基本的
Student和一个StudentWithCourses作为快速破解，这并不是世界末日，但它可能会很快变得混乱。您最终可能会得到StudentWithContacts或StudentWithCoursesButNotContacts等...您明白我的观点，它并不是真正的面向对象设计。通过延迟加载，您的模型中将只有一个 Student 实体，该实体更接近真实域。也就是说，实现延迟加载并不是一件简单的事。因此，如果时间紧迫，请参加两门课程。当您有时间重构时，您可以添加延迟加载。
（当然，您也可以使用现有的数据映射 ORM，例如 Doctrine。）
I'd say it's a trade-off. Design-wise, the lazy loading route would be the best to take. You don't really want artificially different types of Student floating around, clogging up your domain model. Sure it's not the end of the world if you have a basic
Studentand aStudentWithCoursesas a quick hack, but it could get messy fast. You might end up with aStudentWithContacts, orStudentWithCoursesButNotContacts, etc... you see my point, it's not really object-oriented design. With lazy loading you'll only have one Student entity in your model, which is closer to the real domain.That said, it won't be entirely trivial to implement lazy loading. So if time is of the essence, go with the two classes. When you get time to refactor you can add the lazy loading.
(Or, of course, you can use an existing data mapping ORM such as Doctrine.)