标签: business-logic

我正在开发一个新的应用程序,一个经理正在推动业务规则管理系统(BRMS)和工作流管理系统的概念,我正在试图找出集成这些类型的最佳方法工具.

关于这些类型的系统,我不知道我不知道什么,所以我试图获得其他观点和信息.

管理者正在寻找的是业务用户无需开发人员时间(或开发人员时间最短)即可更改业务规则或流程的能力.

当我想到它如何适合代码时,我更容易理解BRMS.它非常简单,我可以看到逻辑如何完全驻留在应用程序之外.由于我没有对这些类型的系统做过多少工作,我将非常感谢有关与.NET集成的优质产品的任何信息,或者有关体验的信息.(我们正在关注InRule,Blaze Advisor和ILOG规则)

我不太确定的是工作流程部分.

Workflow Foundation对我来说很有意义,因为它是一个已知的,已定义的工作流程,它集成到应用程序代码中,但是管理员不是在寻找基础,他想要一个允许业务用户定义和更新工作流程的工具.允许最终用户动态创建工作流的任何类型的系统对我来说都不太合理.

我被要求将WorkflowGen视为工作流引擎的一个示例.对我而言,除非开发人员将.NET代码编写为与后端系统接口,否则它看起来完全是自包含的.

我可以理解一个工作流程系统,它允许用户定义特定的,有限的操作,如"电子邮件等等"和"需要批准",但我不知道应该如何动态定义应用程序的工作流系统flow可以集成到应用程序中,甚至可以集成到我刚刚描述的更简单的系统如何显示和更新后端数据.

我正在推动用例,这样我就可以更好地理解我的manger在应用程序代码之外移动这些类型的逻辑方面正在寻找的东西,但与此同时,我很欣赏任何人在这些类型的系统上的任何信息.正如我所说,我不知道我不知道什么,我们的业务用户似乎认为我们的新应用程序应该支持这些类型的工具.我想确保由于缺乏知识而限制了我们的功能.

感谢您提供任何信息或建议.

请考虑以下代码:

partial class OurBusinessObject {
    partial void OnOurPropertyChanged() {
        if(ValidateOurProperty(this.OurProperty) == false) {
            this.OurProperty = OurBusinessObject.Default.OurProperty;
        }
    }
}

也就是说,当OurPropertyin 的值OurBusinessObject改变时,如果该值无效,则将其设置为默认值.这种模式让我感觉像代码味道,但其他人(在我的雇主)不同意.你的想法是什么？

编辑补充:我被要求添加一个解释为什么这被认为是好的.我们的想法是,业务对象可以验证自己的属性,并在验证失败的情况下设置干净的默认值,而不是让业务对象的生产者验证数据.此外,有人认为,如果验证规则发生变化,业务对象生产者将不必更改其逻辑,因为业务对象将负责验证和清理数据.

我已经阅读了很多关于这些内容的内容,而且我目前正在开发一个更大的Web应用程序及其相应的后端.

但是,我开始使用一种设计,我要求Repository从数据库中获取数据并将其映射到DTO.为何选择DTO？仅仅因为到目前为止基本上一切都是简单的东西,不再需要复杂性.如果它有点复杂,那么我开始直接在服务层中映射例如1到n的关系.就像是:

// This is Service-Layer
public List<CarDTO> getCarsFromOwner(Long carOwnerId) {

    // Entering Repository-Layer
    List<CarDTO> cars = this.carRepository = this.carRepository.getCars(carOwnerId);
    Map<Long, List<WheelDTO>> wheelMap = this.wheelRepository.getWheels(carId);

    for(CarDTO car : cars) {
        List<WheelDTO> wheels = wheelMap.get(car.getId());
        car.setWheels(wheels);
    }

    return cars;
}

这当然是有效的,但事实证明,有时事情变得比这更复杂,我开始意识到,如果我不对此做任何事情,代码可能看起来很丑陋.

当然,我可以加载wheelMap,在CarRepository那里进行轮映射,只返回完整的对象,但由于SQL查询有时看起来很复杂,我不想获取所有cars 和他们的wheels加号处理映射getCars(Long ownerId).

我显然错过了商业层,对吗？但我根本无法理解其最佳实践.

我们假设我有Car一个Owner业务对象.我的代码看起来像这样:

// This is Service-Layer
public List<CarDTO> getCarsFromOwner(Long carOwnerId) {

    // The new Business-Layer
    CarOwner carOwner = new CarOwner(carOwnerId);
    List<Car> …

我正在研究决策引擎/规则评估引擎.例如:

输入:客户和客户完成的所有违规行为

产出:违法行为的后果

一个示例案例是:

输入:客户(Jhonny Chimpo,999-00-1111),犯罪(打破了窗口,打了一个老板,在他的腹股沟中踢了团队领导)

输出:获得粉红色滑动

因此,我想写的代码片段根据每个攻击和组合攻击的规则评估不同的攻击.当前代码只是if和else语句的迷宫.我确信这些业务问题很常见.通常使用什么设计/企业模式来解决这样的问题？

这是规格模式吗？我希望代码是开放的扩展,干净和灵活.

我有一个与Doctrine 2和Zend Framework有关的问题.

如果默认使用Zend Framework而不使用Doctrine,则将业务逻辑放在模型中.但是,由于Doctrine 2确实有实体应该放置业务逻辑吗？

我首先创建了实体管理器调用实体的模型.但是当我想在没有数据库调用的情况下为我的模型编写单元测试时.我需要将实体管理器移动到控制器.但我在控制器中获得的业务逻辑并不好.

下面的代码显示了控制器操作的一部分:

        $customerAddress = $this->_model->save($values, $id);

        $this->_em->persist($customerAddress);

        // Update default billing address
        $defaultBilling = $this->_model->saveDefaultBilling($values, $customerAddress);
        if ($defaultBilling != FALSE) {
            $this->_em->persist($defaultBilling);
        }

        // Update default shipping address
        $defaultShipping = $this->_model->saveDefaultShipping($values, $customerAddress);
        if ($defaultShipping != FALSE) {
            $this->_em->persist($defaultShipping);
        }

        $this->_em->flush();

有人可以说这个问题的最佳做法是什么？谢谢

验证规则和业务规则之间有什么区别？

根据我的理解,'如果业务对象/对象的状态不符合预期,则抛出错误消息'是验证规则,'当业务对象/对象的状态等于或不等于某事时,然后更改某些业务对象/对象的状态[或采取一些操作/事件但不仅仅是抛出错误]'是业务规则.

验证可以是UI验证 - 验证UI字段或应用程序验证的值 - 验证业务对象状态.

我不确定我的理解是否正确.在我的项目中,我们有一个验证框架,其中一个简单的验证调用使业务对象对某些东西进行验证,一个错误收集器收集所有错误.错误显示在屏幕上.

除此之外,我们还有如上所述属于第二类的规则,即检查业务对象/对象状态并采取一些操作,例如更改另一个业务对象的状态.我试图找出使用一些框架[不是验证框架]或规则引擎来实现这些规则的策略.

能否帮助我理解上述两种规则之间的区别,如果有任何实施策略/建议,它会有所帮助.

我正在试图找出构建易于维护和可测试的架构的最佳方法.经历了几个项目之后,我看到了一些非常糟糕的架构,我想避免在我自己的项目中犯下未来的错误.

假设我正在构建一个相当复杂的三层应用程序,我想使用DDD.我的问题是,我应该在哪里放置我的业务逻辑？有人说它应该放在服务(服务层)中,这确实有意义.拥有一系列遵循单一责任原则的服务是有道理的.

但是,有些人说这是反模式,业务逻辑不应该在服务层实现.为什么是这样？

假设我们有IAuthenticationService一个带bool UsernameAvailable(string username)签名的方法.该方法将实现所有必需的逻辑以检查用户名是否可用.

根据"这是一个反模式"的人群,这里有什么问题？

我想就如何在简单的C#Windows窗体应用程序中分离UI和业务逻辑提出一些建议.

我们来看这个例子:

UI由简单的文本框和按钮组成.用户输入0到9之间的数字并单击该按钮.程序应该为数字添加10并使用该值更新文本框.

业务逻辑部分应该不知道UI.如何实现这一目标？

这是空的Process类(业务逻辑):

namespace addTen
{
    class Process
    {
        public int AddTen(int num)
        {
            return num + 10;
        }
    }
}

要求是:

1. 当用户单击该按钮时,会以某种方式调用Process :: AddTen.
2. 必须使用Process :: AddTen的返回值更新文本框.

我只是不知道如何连接这两个.

问候!

在基于Web的项目上工作是业务规则和逻辑需要由客户定制.我想这样做,而不必每次在系统上注册新客户端时重新编译应用程序.我到目前为止概述的架构是:

1. Windows工作流:创建动态工作流并将其保存到数据库.
2. 思考:创建业务规则界面并使用反射来加载自定义客户端程序集.
3. 真正的业务规则引擎
4. 实现像结构图一样的IOC容器.[zaff:已添加6/4]

你有没有实现类似的东西？如果是这样,你的经历是什么？最后还有另一种我应该探索的解决方案吗？

谢谢你的帮助!!

在我看来,业务对象的ID字段应该是只读的(公共get和私有集),因为根据定义,ID永远不会改变(因为它唯一地标识数据库中的记录).

这会在您创建新对象(尚未设置ID)时产生问题,通过存储过程将其保存在数据库中,例如返回新创建的ID,如果读取ID属性,如何将其存储回对象-只要？

例:

Employee employee = new Employee();  
employee.FirstName="John";  
employee.LastName="Smith";  

EmployeeDAL.Save(employee);

如果此属性是只读的,那么Save方法(实际连接到数据库以保存新员工)如何更新Employee对象中的EmployeeId属性(应该是EmployeeId在创建后永远不会更改).

看起来Id应该可以由DAL写入,并且只读给世界其他地方.如果DAL类和Business对象在不同的​​程序集中,您如何实现这一点？

我不想在Employee类中创建一个Save方法,因为这个类应该与数据库无关.