存储库模式与“智能"模式业务对象 [英] Repository pattern vs. "smart" business objects

问题描述

在 .NET(Winforms、WPF、ASP.NET)上创建更大规模的企业级应用时，我看到了两种主要的思想流派".

I see two main "schools of thoughts" when it comes to creating larger-scale enterprise-wide apps on .NET (Winforms, WPF, ASP.NET).

有些人使用存储库模式"，它使用知道如何获取、插入、更新和删除对象的存储库.这些对象相当愚蠢"，因为它们不一定包含大量逻辑 - 例如它们或多或少是数据传输对象.

Some folks use the "repository pattern" which uses a repository that knows how to fetch, insert, update and delete objects. Those objects are rather "dumb" in that they don't necessarily contain a whole lot of logic - e.g. they're more or less data-transfer objects.

另一个阵营使用我称之为智能"业务对象的东西，它们知道如何加载自己，它们通常有一个 Save()、可能的 Update() 甚至 Delete() 方法.在这里，您真的不需要任何存储库 - 对象本身知道如何加载和保存自己.

The other camp uses what I call "smart" business objects that know how to load themselves, and they typically have a Save(), possibly Update() or even Delete() method. Here you really don't need any repository - the objects themselves know how to load and save themselves.

大问题是:您使用或喜欢哪个?为什么?

Big question is: which do you use or prefer? And why?

您是否在所有应用中使用相同的方法，或者您有什么特定的标准何时选择一种方法而不是另一种方法?如果是这样 - 这些标准是什么?

Do you use the same approach in all your apps, or do you have any particular criteria when to choose one approach over the other? If so - what are those criteria?

我不是要在这里展开一场激烈的战争 - 只是想了解每个人对此的看法以及您的看法，以及您为什么使用一种(或两种)模式而不是另一种模式.

I'm not trying to start a flame-war here - just trying to find out what everyone thinks about this and what your opinion is, and why you use one (or both) patterns over the other.

感谢您的任何建设性意见！

Thanks for any constructive input!

推荐答案

我使用存储库模式是因为单一职责原则.我不希望每个单独的对象都必须知道如何保存、更新、删除自己，而这可以由一个单一的通用存储库处理

I use the repository pattern because of the Single Responsibility Principle. I don't want each individual object to have to know how to save, update, delete itself, when this can be handled by one single generic repository

这篇关于存储库模式与“智能"模式业务对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！