标签: business-logic

目前我们正在使用检查约束来实现业务规则,但我想知道是否应该在SQL或业务逻辑层(C#)中实现业务规则.我在网上搜索过,发现检查约束很好用.

如果有人知道有关它的详细信息,请告诉我.还有一件事是,可以使用移动应用程序以及使用Web应用程序将数据泵入我的数据库.

考虑到我希望能够将用户保存到数据库,我的添加操作如下:

    public function addAction()
    {

    $form = new UserForm();
    $form->get('submit')->setValue('Add');

    $request = $this->getRequest();

    if ($request->isPost()) {

        $userFilter = new UserFilter();
        $form->setInputFilter( $userFilter->getInputFilter() );
        $form->setData( $request->getPost() );

        if ($form->isValid())

            $user = new User();
            $user->setEmail($form->getInputFilter()->getValue('email')  );
            $user->setNome( $form->getInputFilter()->getValue('name') );


            $em = $this->getServiceLocator()->get('Doctrine\ORM\EntityManager');
            $em->persist($user);
            $em->flush();


            return $this->redirect()->toRoute('user');

        }
    }

    return array('form' => $form);
    }

很容易将用户保存到数据库,但是如果我需要添加一些复杂的业务逻辑,那么我想检查电子邮件是否是唯一的,并且我还想访问一些Web服务来检查生命的终极问题的答案,宇宙,一切都是42,如果是真的我想将用户保存到数据库,如果不是我想向用户显示一条消息.

它可以完成添加操作但是我告诉这不是一个很好的做法,我可以把这个业务逻辑放在实体User中,但是这会在实体中添加zf2和doctrine之间的耦合,这也很糟糕.在网上搜索解决方案,答案似乎是将业务逻辑放在服务层中.

通过使用服务层解决方案,可以创建一个UserBusinessLogic类并创建一个方法save,它将执行业务逻辑并在一切正常时保存用户.

这听起来不错吗？有关于这个问题的文件吗？也许是一个代码示例,展示了如何使用doctrine 2和zf2以及服务来处理业务逻辑.

我想底线是:在使用zf2和doctrine 2时,将业务逻辑放在哪里的最佳做法是什么？

假设服务解决方案是最好的方法.如果我有实体用户,组以及这两者之间的关系,我会创建一个名为"access"的服务,这个服务将是从控制器接收数据以保存用户组,链接那些2并执行任何其他任务的服务.发送邮件以重置用户密码.这听起来不错吗？

我正在尝试使用Haskell的QuickCheck,虽然我熟悉测试方法背后的概念,但这是我第一次尝试将它用于一个超出测试类似的项目的那个项目reverse . reverse == id.事情.我想知道将它应用于业务逻辑是否有用(我认为非常可能).

因此,我想测试的几个现有业务逻辑类型函数如下所示:

shouldDiscountProduct :: User -> Product -> Bool
shouldDiscountProduct user product =
  if M.isNothing (userDiscountCode user)
     then False
     else if (productDiscount product) then True
                                       else False

对于此功能,我可以编写如下的QuickCheck规范:

data ShouldDiscountProductParams
  = ShouldDiscountProductParams User Product

instance Show ShouldDiscountProductParams where
  show (ShouldDiscountProductParams u p) =
    "ShouldDiscountProductParams:\n\n" <>
    "- " <> show u <> "\n\n" <>
    "- " <> show p

instance Arbitrary ShouldDiscountProductParams where
  arbitrary = ShouldDiscountProductParams <$> arbitrary <*> arbitrary

shouldDiscountProduct :: Spec
shouldDiscountProduct = …

我有一个团队负责人似乎认为业务逻辑是非常主观的,以至于如果我的存储过程有WHERE ID = @ID- 他会称之为"业务逻辑"

我应该采取什么方法以非常客观的方式定义"业务逻辑",而不会冒犯我的团队负责人？

我在这里寻找指针和信息,我会做这个CW,因为我怀疑它没有一个正确答案.这是针对C#的,因此我将在下面对Linq进行一些引用.我也为这篇长篇大论道歉.让我在这里总结一下这个问题,然后是完整的问题.

简介:在UI/BLL/DAL/DB 4层应用程序中,如何更改用户界面,以显示更多列(例如在网格中),避免泄漏通过业务逻辑层进入数据访问层,掌握要显示的数据(假设它已经在数据库中).

让我们假设一个有3(4)层的分层应用程序:

• 用户界面(UI)
• 业务逻辑层(BLL)
• 数据访问层(DAL)
• 数据库(DB;第4层)

在这种情况下,DAL负责构造SQL语句并对数据库执行它们,返回数据.

"正确"构建这样一个层的唯一方法就是总是"select*"吗？对我来说这是一个很大的禁忌,但让我解释为什么我在想.

让我们说,对于我的用户界面,我希望显示所有拥有活跃就业记录的员工."活跃"是指今天的就业记录包含今天(或者甚至是我可以在用户界面中设定的日期).

在这种情况下,假设我想向所有这些人发送一封电子邮件,因此我在BLL中有一些代码可以确保我还没有向同一个人发送过电子邮件,等等.

对于BLL,它需要最少量的数据.也许它调用数据访问层来获取活动员工列表,然后调用以获取它发送的电子邮件列表.然后它加入这些并构造一个新列表.也许这可以在数据访问层的帮助下完成,这并不重要.

重要的是,对于业务层,它实际上并不需要太多数据.也许它只需要每个员工的唯一标识符,对于两个列表,匹配,然后说"这些是活动的那些的唯一标识符,您还没有发送电子邮件到".然后构建DAL代码,构造只检索业务层需要的SQL语句吗？IE浏览器.只是"SELECT id FROM employees WHERE ..."？

那么我该怎么做用户界面呢？对于用户来说,这或许会是最好的,包括了很多信息,这取决于为什么我要发送电子邮件.例如,我可能想要包括一些基本的联系信息,或者他们工作的部门,或者他们的经理姓名等,而不是说我至少要显示姓名和电子邮件地址信息.

用户界面如何获取数据？我是否更改了DAL以确保将足够的数据返回给UI？我是否更改BLL以确保它为UI返回足够的数据？如果从DAL返回到BLL的对象或数据结构也可以发送到UI,那么BLL可能不需要进行太多的更改,但是UI的要求会影响超出应该与之通信的层. .如果这两个世界在不同的数据结构上运行,则可能必须对两者进行更改.

那么当UI被更改时,为了进一步帮助用户,通过添加更多列,我需要多深才能更改UI？(假设数据已存在于数据库中,因此不需要进行任何更改.)

提出的一个建议是使用Linq-To-SQL和IQueryable,这样如果DAL处理什么(如在什么类型的数据中)和为什么(如WHERE-clauses中)返回IQueryables,那么BLL可以可能会将这些内容返回到UI,然后可以构建一个Linq查询来检索所需的数据.然后,用户界面代码可以拉入所需的列.这将有效,因为使用IQuerables,UI最终会实际执行查询,然后它可以使用"select new {X,Y,Z}"来指定它需要的内容,甚至可以在必要时加入其他表.

这看起来很混乱.UI执行SQL代码本身,即使它已隐藏在Linq前端后面.

但是,为了实现这一点,不应该允许BLL或DAL关闭数据库连接,并且在IoC类型的世界中,DAL服务可能比UI代码所希望的更快地被处理掉,因此Linq查询可能最终会出现"无法访问已处置对象"的异常.

所以我正在寻找指针.我们有多远？你是怎么处理的？我认为UI的更改将通过BLL泄漏到DAL中是一个非常糟糕的解决方案,但是现在它看起来并不像我们能做得更好.

请告诉我我们有多愚蠢并证明我错了？

请注意,这是一个遗留系统.多年来,更改数据库模式的范围还不在范围内,因此使用ORM对象的解决方案基本上与"select*"相当,实际上并不是一种选择.我们有一些大型表格,我们希望避免在整个图层列表中提取.

让我们假设一个应用程序在模型/表示层中具有所有必要的业务规则,并且它们工作正常.我的问题是,是否应在SQL Server等存储库中使用冗余业务规则(即两个日期的跨度不能与任何其他现有跨度重叠).

在SQL Server中添加强制执行此规则的约束是否必要/有益？一方面,它可以防止任何人(包括DBA)在绕过应用程序时无意中破坏业务规则.此外,我们已经通过主键和外键在存储库中拥有某些形式的业务规则.另一方面,重复的规则需要额外的时间来开发和维护.

这个问题涵盖了许多不同的技术,所以我故意保持标签的通用性.

我是appcelerators钛和javascript的新手,我对编写iPhone应用程序很感兴趣.我认识到需要"很多"代码来创建UI.到目前为止这没问题,但我倾向于明智地将该代码与我的应用程序逻辑分开.什么是最佳做法？

[更新] tweetanium是如何构建钛移动应用程序的一个很好的例子

很多时候我都听说过这两个概念.

如"windows工作流基础"和Activiti和jBPM等项目是"业务流程管理引擎".

这两个名词("工作流引擎"和"业务流程管理引擎")是一回事吗？

我想知道如何管理BLoC模式Firebase.我找不到任何例子BLoC的Firebase,所以可能是广泛的,但请原谅我.我看到了一些基本的BLoC实现,但那些基本上是以主动方式获取数据或更新视图,而不是被动方式也不是通过数据库(几乎是API JSON的东西).因此,当用户更新自己的个人资料信息时,我想看看如何处理类似get get(被动方式)的某些BLoC模式Firestore.有没有人以正确的方式引导我？任何帮助都非常感谢!

我对在基于六边形架构的应用程序中处理域事件的位置感到困惑。我说的是有界上下文内部域事件，而不是上下文间集成/应用程序/公共事件。

背景

据我了解，应用程序逻辑（即用例逻辑、工作流逻辑、与基础设施的交互等）是命令处理程序所属的地方，因为它们特定于特定的应用程序设计和/或 UI 设计。然后命令处理程序调用域层，所有域逻辑都驻留在其中（域服务、聚合、域事件）。领域层应该独立于特定的应用程序工作流程和/或 UI 设计。

在许多资源（博客、书籍）中，我发现人们在应用程序层中实现域事件处理程序，类似于命令处理程序。这是因为域事件的处理应该在其自己的事务中完成。由于它可能会影响其他聚合，因此必须首先通过基础设施加载这些聚合。然而，关键点是：领域事件被分解并变成对聚合的一系列方法调用。这个重要的转换仅存在于应用层。

问题

我认为关于哪些领域事件会对其他聚合产生什么影响的知识是领域知识本身的一个组成部分。如果我要删除除域层之外的所有内容，那么这些知识不应该保留在某个地方吗？在我看来，我们应该将域事件处理程序直接放置在域层本身中：

• 它们可以是域服务，接收域事件和可能受其影响的聚合，并将域事件转换为一个或多个方法调用。

• 它们可以是聚合本身的方法，直接消耗整个域事件（即签名包含域事件类型）并对其执行任何操作。

当然，为了加载受影响的聚合，我们仍然需要在应用层有一个相应的处理程序。该处理程序仅启动一个新事务，加载感兴趣的聚合并调用域层。

由于我从未在任何地方看到过这一点，我想知道我是否对 DDD、领域事件或应用程序层和领域层之间的差异有什么误解。

编辑：示例

让我们从这种常用的方法开始：

// in application layer service (called by adapter)
public void HandleDomainEvent(OrderCreatedDomainEvent event) {
    var restaurant = this.restaurantRepository.getByOrderKind(event.kind);
    restaurant.prepareMeal(); // Translate the event into a (very different) command - I consider this important business knowledge that now is only in the application layer.
    this.mailService.notifyStakeholders();
}

换成这个怎么样？

// in application layer service (called by adapter)
public void HandleDomainEvent(OrderCreatedDomainEvent event) {
    var …