2

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

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

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

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

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

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

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

4

3 回答 3

3

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

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

编辑：回应您的评论：

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

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

public class Product {
    public decimal GetPriceFor(User user) {
        // logic to determine per-user pricing goes here:
    } 
}
于 2009-03-01T10:56:53.443 回答
2

一种方法是创建一个包含业务逻辑的服务层。服务层与存储库交互，应用您需要的任何规则或过滤器。这意味着从服务层返回的任何东西都只是一个普通的 c# 对象 (POCO)。

于 2009-03-01T14:13:28.650 回答
0

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

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

可以很容易地识别关系：客户和产品。

客户类：customerName、customerDetail

产品类：productName、productDetail

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

类 CustomerProduct：customerName、productName、productPrize

因为你可以认为只有customerName X productName |-> productPrize。对于用例客户 C 想知道产品 P 的价格：

客户('C').prize('P')

必须委派方法奖品才能知道确切的奖品，并且您可以清楚地分离关注点。明确一点：BO 不会向客户展示任何奖品。只是该方法可以访问敏感数据。您可以限制此访问权限。

于 2009-03-01T16:16:23.363 回答