Question

角色/视图逻辑是属于存储库模式的内部还是外部？

例如，我有一个产品表，每个产品有5个价格字段 - 每种类型的客户一个（批发，零售等）。

我只想向适当的用户显示适当的价格。

如果我有这些产品的存储库，是否应返回Product业务对象，包含所有5个价格，并以某种方式仅显示相关价格？

如果是这样，使用什么样的好模式？

我是否应该创建一个视图对象，它接受业务对象和角色并确定要显示的正确价格？或者我应该将该逻辑放在业务对象中？

（仅供参考：如果您认为它有助于构建响应，我将在ASP MVC中构建解决方案）

Answer 1

是的，您的存储库应该返回所有五个价格，您的对象应该包含决定哪个客户收到哪个价格的业务逻辑。无论数据来自哪里，对象都应该能够做出这个决定。

此方法还允许您独立于数据访问问题测试定价逻辑 - 例如，通过使用'虚拟'存储库，手动创建已填充五个价格字段的产品，或使用模拟用于模拟存储库调用的框架。将这种逻辑移到业务对象之外 - 例如将它放在您的数据访问层中 - 可能会导致称为Anemic Domain Model的反模式。

编辑：回应你的意见：

术语“存储库”专门指的是返回业务对象的完全填充集合（聚合）的数据访问模式。如果您发现返回DTO是解决问题的更好解决方案，那么请继续执行此操作，但如果您使用术语“存储库”来引用其他数据访问模式，则可能会让人感到困惑。就个人而言，我坚持使用存储库方法并返回完全填充的业务对象，因为我更喜欢以这种方式工作，但同样如此，它取决于您正在构建的系统的规模和复杂性。

要公开定价逻辑，您可能只想使用如下方法：

public class Product {
    public decimal GetPriceFor(User user) {
        // logic to determine per-user pricing goes here:
    } 
}

Answer 2

一种方法是创建包含业务逻辑的服务层。服务层使用您需要的任何规则或过滤器与存储库进行交互。这意味着从服务层返回的任何内容都只是一个简单的c＃对象（POCO）。

Answer 3

在设计了一些带有额外数据访问层的产品之后，我会说：设计它时考虑到功能依赖性！

假设您对数据字典有以下非常常见的结构：productName，productDetail，productPrice，customerName，customerDetail。

可以轻松识别关系：客户和产品。

类Customer：customerName，customerDetail

类产品：productName，productDetail

但是要绘制第三种关系，它是

class CustomerProduct：customerName，productName，productPrize

因为您可以说明只有customerName X productName | - ＆gt; productPrize。对于用例，客户C想知道产品P的价格：

客户（ 'C'）。奖（ 'P'）

必须委派方法奖才能知道确切的奖品，并且您可以清楚地分离关注点。要明确这一点：BO将向客户显示 no 奖品。只是该方法可以访问精细数据。您可以限制此访问权限。

角色/视图是属于存储库模式的内部还是外部？

3 个答案: