标签: business-logic

我有两个与 CQRS 和领域驱动设计 (DDD) 相关的问题。

据我了解 CQRS 背后的隔离思想，一个会有两个独立的模型，一个读模型和一个写模型。只有写入模型才能通过命令访问和使用业务域模型。而读取模型则是通过查询的方式直接将数据库内容转化为DTO，根本无法访问业务领域。

对于上下文：我正在编写一个 Web 应用程序后端，为粒子物理提供计算服务。现在我的问题：

1.) 我的业务领域逻辑包含一些函数，这些函数计算数学值作为给定测量系统配置的输出作为输入。因此，从技术上讲，这些是只读查询，可以即时计算值，并且不会更改任何模型中的任何状态。因此，它们应该是读取模型的一部分。然而，因为这些功能与域密切相关，所以它们必须是域模型的一部分，而域模型又是写模型的一部分。当应该包含所有查询的读取模型无法访问域模型时，我应该如何通过我的 API 使这些计算函数可用于前端？

我真的必须触发命令将所有计算保存到数据库中，以便读取模型可以访问计算结果吗？这些“一次性”计算只会被前端短期使用，以后没有人需要访问持久的计算结果。必须是测量配置，而不是计算结果。每当用户点击前端的“计算”按钮时，这些将被重新计算多次。

2.) 我也觉得我复制了很多数据验证代码，因为读模型和写模型都必须反序列化和验证流程链中相同或非常相似的请求参数http request body -> json -> unvalidated DTO -> validated value -> command/query. 我应该如何处理？我可以在读取模型和写入模型之间共享验证代码吗？这似乎消除了隔离。

在此先感谢您的帮助和想法。

12 mtd,12 mtd轧制和ytd计算之间的区别是什么

我需要将工作时间添加到时间戳.工作时间为上午8点至下午6点.让我们说我们有下午2点,我必须增加6个小时.结果应该是上午10点......任何猜测？

谢谢.

我有一个项目,其中一些业务逻辑被分离到DLL项目,该DLL包含针对特定客户的此软件的业务逻辑.

现在我遇到了一个问题,在另一个具有不同规则的客户端想要实现该软件之后,我需要一些应用程序根据客户端使用该软件加载适当的dll,考虑到这个dll包含相同的函数名但不同的主体.

我正在使用c#3.5,有没有办法这样做？

可以使用术语业务逻辑来描述：

控制最终用户可以使用哪些数据的帐户角色（管理员、最终用户、未注册用户、主持人）？

如果没有，有人可以提供一个术语来描述上述情况，并准确地纠正我的业务逻辑意味着什么？它与业务规则有何不同？例子？您会将业务逻辑层放在 Rails/RoR 中的控制器中吗？

我讨厌再次提出"数据库与代码中的业务逻辑"的经典问题,但我需要一些具体的理由来说服开发人员的老团队,代码中的业务逻辑更好,因为它更易于维护,最重要的是.我以前在DB中有很多业务逻辑,因为我认为它是单点访问.如果我是唯一一个改变它的人,那么维护很容易.根据我的经验,当项目变得更大和更复杂时,问题就出现了.DB存储过程的源控制不像新IDE那样先进,编辑也不是.代码中的业务逻辑可以比DB更好地扩展,这是我在最近的经验中发现的.

所以,只是搜索stackoverflow,我发现了与其尊敬的成员相反的哲学:

https://stackoverflow.com/search?q=business+logic+in+database

我知道任何情况都不是绝对的,但是对于一个给定的asp.net解决方案,它将使用sql server或oracle,对于一个不是特别高的流量站点,为什么我会把逻辑放在DB中呢？

这是一个高级项目组织问题.

组织包含许多子应用程序的项目/解决方案(Visual Studio)的"正确"方法是什么？

这必须是大型企业级项目中的常见问题.任何人都可以指向白皮书/书籍/链接,以帮助决定如何构建这个？

在24小时内学习企业架构将是完美的,但似乎并不存在.

我们的第一次尝试遵循3层服务架构,但除了通用业务功能(ProcessOrder(..),BalanceAccount(..)等),我们还需要特定于应用程序的数据.

遵循n层架构,所有应用程序仍然需要通过BLL - > DLL来获取任何信息(ViewModel,特定于应用程序的数据).

一些模型类(BOM)是通用的,可以在整个过程中使用(订单,账单,账户,客户等)

一种选择是将所有业务实体集中在同一个Enterprise.BOM项目下,并具有多个名称空间 - 一些是全局的,一些是ViewModel类的特定应用程序.

然后BLL和DAL层将遵循相同的组织 - 每个应用程序都有自己的命名空间,并且在任何地方使用的东西都放在根命名空间中.

但随着应用程序数量的增长,重用现有对象/进程将是一项挑战(即每个应用程序可能需要对Bill信息执行某些操作,但不应定义自己的Bill类,而应使用BLL/DAL中的现有类).

从顶部强制要求的另一个方向是以SOA-izable方式开发所有内容:"应用程序"有效地成为BLL中定义的所有流程业务逻辑的视图/工作流,因此"应用程序"(基本上是UI)可以替换为服务层向外部系统公开功能.

如果相关,我们是一个带有规则引擎的.NET商店,但是没有工作流程(虽然它可能在一两年内,因此未来的WS集成很重要).

提前致谢!

我试图打破一些编写错误代码的旧习惯.其中一个是放置验证码的地方.我不认为验证应该在表示层中.或者那里可能有一些验证？

这是我过去做的一个例子

protected void SaveBtn_Click(object sender, EventArgs e)
{

  Item itm = new Item();
  itm.Name = txtName.Text;

  if(String.IsNullOrEmpty(itm.Name))
  {
     //reject
  }
  else
  {
     ItemBLL.Save(itm); //no more validation here
  }
}

要么

public class ItemBLL
{

   public static int Save(Item itm)
   {
      //no more validation in .aspx.vb
      if(String.IsNullOrEmpty(itm.Name))
      {
        //reject
      }
      else
      {
       //Save item
      }
   }
}

我一直在使用第一种方法,我正在考虑切换到第二种方法,但我无法预测问题会是什么或一方面的优势.即使是更好的方法,也请赞赏

更新: 我同意,为了用户的简单验证(例如常见错误)应该在演示文稿(.aspx)中完成(使用javascript,jQuery).

一些业务逻辑验证也应该驻留在BLL中,以实现可移植性和可重用性.

这是否意味着我们可以在代码隐藏(.aspx.vb或.aspx.cs)中跳过验证？

遵循 CQRS（命令查询职责分离）的概念，我在我的 MVC 应用程序中直接引用 DAL，并通过 ViewModel 进行所有读取。然而，我的一位同事问我，当阅读时必须应用任何业务逻辑时，你会怎么做。例如，如果您需要在如下场景中计算百分比值：

//Employee domain object
class Employee
{
    string EmpName;
    Single Wages;
}

//Constant declared in some utility class. This could be stored in DB also.
const Single Tax = 15;

//View Model for the Employee Screen
class EmployeeViewModel
{
    string EmpName;
    Single GrossWages;
    Single NetWages;
}


// Read Facade defined in the DAL
class ReadModel
{
    List<EmployeeViewModel> GetEmployeeList()
    {
        List<EmployeeViewModel> empList = new List<EmployeeViewModel>;
        string query = "SELECT EMP_NAME, WAGES FROM EMPLOYEE";      
        ...
        .. …

在阅读https://softwareengineering.stackexchange.com/questions/165444/where-to-put-business-logic-in-mvc-design/165446#165446后，我仍然对要将代码放置在何处感到困惑计算折扣。我认为计算产品或服务的折扣价绝对是业务逻辑的一部分，而不是应用程序路由或数据库交互的一部分。因此，我正在努力将业务逻辑放在何处。

例

class Model
{
    public function saveService($options)
    {
        $serviceId = $options['service_id'];

        //Model reads "line Item" from database
        $service = $this->entityManager->find('Entity\ServiceLineItem', $serviceId);
        //uses the data to compute discount
        //but wait.. shouldn't model do CRUD only?
        //shouldn't this computation be in Controller?   
        $discount = ($service->getUnitPrice() * 0.25);

        // Add the line item
        $item = new SalesItem();
        $item->setDiscount($discount);
    }
}


class Controller
{
    function save()
    {
        $this->model->saveService($options);
    }
}

题：

在$discount计算之上，它应该留在模型中还是应该留在Controller中？如果进入控制器，则控制器必须先调用$service（通过模型），然后$discount在控制器内部进行计算，然后将其值发送回要保存的模型。那是这样做的方式吗？

注意

我可能会将模型与“存储”混淆。我可能需要一个执行业务逻辑的模型，而数据库/持久性存储应该是一个单独的层。

我正在和一个客户一起重振他14年前使用Foxpro2.6开发的旧软件.我的问题是客户端只有源代码(以.prg文件的形式)和数据库文件,但源代码中既没有任何文档也没有注释来指导我做什么...甚至数据库文件都没有正确命名.我在这种情况下的唯一选择似乎是通过.prg文件,并了解哪个命令更新哪个数据库记录和如何....但有大约300 .prg文件,我根本不知道Fox Pro(我的意思是我当这个东西变得过时时,它已经达到了第9个标准!).

任何建议或想法使这项工作变得简单,也许是一个.prg到C转换器,它可以帮助我很多.

请帮助....它正在成为一场噩梦

PS:我没有数据库转换的问题,但前端和功能源代码也写在FoxPro2.6并保存为.prg扩展是问题,因为我不知道语言,没有文档.

我正在尝试实现一个业务逻辑层,其中包含一些保存车辆预订数据的用例.关于应该在哪里实现Repository模式,我有点困惑.我应该在BLL或DAL中使用它吗？这听起来很基本,但我在设计阶段有点迷失.如果Repository模式不适合BLL,那么哪个是.任何帮助/提示表示赞赏.