DAL：存储库边界问题
DAL 库公开了数十个存储库。每个实体一个存储库。有 PersonRepository & 照片存储库。
当我向存储库添加新方法并且方法处理实体时，很明显我必须将其放在哪里。如果我想要 CreatePerson 我会创建 PersonRepository::Create(...) 或者当我需要更新照片时我会创建 PhotoRepository::Update
但是当方法处理时对于实体关系，有时事情会变得很虚无。例如，我应该创建 PersonRepository::AssignPhoto(PersonId, PhotoId) 还是应该创建 PhotoRepository::AssingToPerson(PhotoId, PersonId) ？
如果我很清楚（我认为 Person 是比 Photo 更重要的实体，所以我将创建 PersonRepository 方法），一些开发人员找不到合适的方法，并倾向于在 PhotoRepository 中创建重复项。
如何最小化这个问题？
您可能同时创建这两种方法 (PersonRepository::AssignPhoto 和 PhotoRepository::AssignToPerson)（一个方法将调用委托给实现它的另一个方法）？或者我们应该在团队中拥有强大的存储库方法命名约定吗？或者我可能会改变存储库边界的方法？
There is DAL library that exposes dozen of repositories. One repository per entity. There is PersonRepository & PhotoRepository.
When I add a new method to repository and method deals with entity it's obvious where I have to put it. If I want CreatePerson I'll create PersonRepository::Create(...) or when I need to update photo I'll create PhotoRepository::Update
But when method deals with entity relations things come vapor sometimes. Shall I create PersonRepository::AssignPhoto(PersonId, PhotoId) or shall I create PhotoRepository::AssingToPerson(PhotoId, PersonId) for example?
If things are clear to me (I suppose that Person is more important entity than Photo so I'll create PersonRepository method), some developers don't find appropriate method and tend to create duplicates in PhotoRepository.
How do you minimize this issue?
May be you create both methods (PersonRepository::AssignPhoto & PhotoRepository::AssignToPerson) at the same time (one method delegates call to another where it's implemented)? Or shall we have strong repository methods naming convention in the team? Or may be I shall change approach to repository boundaries?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在面向对象的世界中，我有一个带有方法AssignPhoto的Person对象。
处理存储库上的对象关系操作感觉像是一种程序方法，至少对我来说是这样。
In a object oriented world, I'd have a Person object with a method AssignPhoto.
To handle object relation manipulations over the repositories feels like a procedural approach, at least to me.