相关疑难解决方法(0)

我们当前的O/RM工具并不真正允许丰富的域模型,因此我们不得不在各地使用贫血(DTO)实体.这工作正常,但我仍然在努力放置基于对象的基本业务逻辑和计算字段.

当前图层:

• 介绍
• 服务
• 知识库
• 数据/实体

我们的存储库层具有大多数基本的提取/验证/保存逻辑,尽管服务层执行了许多更复杂的验证和保存(因为保存操作也执行日志记录,权限检查等).问题是在哪里放置这样的代码:

Decimal CalculateTotal(LineItemEntity li)
{
  return li.Quantity * li.Price;
}

要么

Decimal CalculateOrderTotal(OrderEntity order)
{
  Decimal orderTotal = 0;
  foreach (LineItemEntity li in order.LineItems)
  {
    orderTotal += CalculateTotal(li);
  }
  return orderTotal;
}

有什么想法吗？

我对感知"最佳实践"感兴趣,在这里用一点点现实来锻炼.

在Web应用程序中,您是否允许您的Web层直接访问DAL,还是应该首先通过BLL？

我特别谈的是没有真正涉及"业务逻辑"的场景 - 比如一个简单的查询:"获取姓氏为'Atwood'的所有客户".那些有任何逻辑的场景绝对会通过BLL,所以我们称之为moo.

虽然您可以将此方法封装在BLL对象中,但是当签名与DLL对象的签名完全相同时,似乎有点无意义,并且代码可能与将查询委派给DLL的一个简单的代码一样简单.

如果选择前者 - 使用BLL对象 - 你称这些对象是什么？(假设它们只是在DLL中提供查询层).助手？QueryProviders？

想一想.

问候

马蒂