数据访问层或具有带有 CRUD 方法的对象？
我曾经有一个数据访问层，它通过参数获取对象并抽象处理所需的持久性类型。在我的新工作中，架构师正在考虑将 CRUD 操作（加载..保存..删除..更新）实现到所有模型对象中。这些方法将有一个通过参数来处理对象保存的对象。示例：加载（IPersistence 持久性）。我对可扩展性有一些疑问，并且每个模型对象都必须实现所有加载、保存、删除、更新方法。
最好的方法是什么？
I used to have a Data Access Layer that take the object by parameter and handle with abstraction the type of persistence required. At my new job, the architect is thinking to implement CRUD operation (load..save..delete..update) into all model object. Those method would have an object by parameter that will handle the saving of the object. Exemple : load(IPersistence persistence). I have some doubt about the extensibility and that each model object would have to implement all load,save,delete,update method.
What is the best approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我想这是一个永恒的问题，这两种方法都有其优点和缺点，并且有很多追随者坚信它们。
您似乎喜欢使用存储库方法（拥有存储库/网关，无论您如何称呼它）来处理 CRUD 操作，使您的实际业务类更小、更精简，因为它们可能只包含数据和可能的验证/业务规则。
在这种情况下，您将实现一次 CRUD 操作 - 但很可能为您正在处理的每种类型的对象实现一次。
另一方面，智能业务对象方法可能会认为给定实体上的 CRUD 操作无论如何都是特定于该实体的，因此选择、更新、删除此类实体的代码始终是具体的，所以它也可能驻留在该对象本身内部。
在这种情况下，您将为每个对象类实现一次 CRUD 操作 - 在这种情况下，我确实没有看到与存储库方法相比有任何大的缺点。
我个人今天倾向于存储库方法，但我也看到了“智能业务对象”方法的好处 - 两者都是有效的，我想您只需要说服您的新架构师您的立场，或者开始术语采用不同的方法。
马克
I guess that's the eternal question and both approaches do have their pros and cons and lots of followers who swear by them.
The
repositoryapproach that you seem to favor (having a Repository/Gateway whatever you call it) to handle the CRUD operations makes your actual business classes smaller and leaner, since they probably only contain data and possibly validation / business rules.In this case, you'd implement the CRUD operations once - but most likely once for each type of object you're dealing with.
On the other hand, the
smart business objectapproach might argue that CRUD operation on a given entity are specific to that entity anyway, so the code to select, update, delete such an entity is always going to be specific, so it might as well reside inside that object itself.In this case, you'd implement the CRUD operations once for each object class - I don't see any big disadvantage over the repository approach in this case, really.
I personally lean towards the repository approach myself today, but I do also see benefits in the "smart business object" approach - both are valid, and I guess you'll just have to either convince your new architect of your position, or get to terms with a different approach.
Marc
达尔一路走来。
您希望能够隔离事务，以便对象不应该知道它们的持久性。否则，代码可能会成为一场难以维护的噩梦，其中对象可以激活数据库往返，并且很难将多个事务滚动到一个原子操作中。
我通过艰难的方式发现了这一点。 :)
DAL all the way.
You want to be able to isolate your transactions so the objects shouldn't be aware of their persistence. Otherwise the code can tend to an unmaintainable nightmare where objects can activate database round trips and it is difficult to roll a number of transactions into one atomic action.
I found out this the hard way. :)
我认为，在这两种情况下，实现都不应该重复，而应该只实现一次并根据需要继承（例如）。
仅非标准作业（例如带有自定义参数的自定义查询）需要子类及其方法。
现在问题就变成了POJO 哲学辩论。让我尝试用自己的话来表达它;-)：
模型没有技术超类的另一个巨大优势是，模型可以用作自己的“数据传输对象”，在系统之间传输该信息：
如果我们的模型类具有技术超类，那么它们在如此不同的上下文中将没有用处。例如：
I think that, in both cases, the implementation should not be repetitive, but implemented only once and inherited (for example) as needed.
Subclasses and their methods would only be needed for non-standard jobs (like custom queries, with their custom parameters).
Now the question amounts to the POJO philosophical debate. Let me try to phrase it in my own words ;-) :
Another huge advantage of having no technical superclass for the model is that the model can be used as its own "data transfer object" to carry that information between systems :
If our model classes would have technical superclasses, they wouldn't be useful in such various contexts. For example: