业务对象和业务逻辑之间有什么区别

Question

我正在尝试根据最佳实践构建我的WPF MVVM应用程序.我必须从很多现有代码开始,所以没有选择立即解决所有结构缺陷.我喜欢以下解决方案结构.

http://www.paulspatterson.com/technology/dot-net-development/mvvm-and-wpf-for-vb-net-series-2-part-1-again/

这将解决方案分为以下项目; BusinessLogic,BusinessObjects,基础结构(通用可重用实用程序),WPF Shell和模块(使用IOC容器注入的应用程序组件).

我理解业务对象代表人类世界实体,而业务逻辑是本问题中讨论的实现细节.

什么是Business Objects,什么是Business Logic？

因此,使用MVVM会使业务对象变成一个愚蠢的容器,除了等待外部业务逻辑更改其属性之外,它实际上什么都不做？我没有看到你如何将业务对象与业务逻辑分离到能够将它们放在单独的程序集中.

采用以下极其简化的代码:

public class Chart
{

    private SizeChart _activeChartSize = new SizeChart();

    public void Draw() {
        //  Size the chart object
        _activeChartSize.Size(this);
        //  Do other draw related things
    }

}

public class SizeChart
{

    public void Size(Chart chartToSize) {
        //  Manipulate the chart object size
    }

}

在上面描述的MVVM解决方案结构的上下文中(至少在我看来),SizeChart类是业务逻辑,Chart类是业务对象,但将它们放在不同的项目中将是循环依赖.如果我采用这个提议的MVVM解决方案结构,那么SizeChart类是业务逻辑还是业务对象以及SizeChart类所在的解决方案结构中的位置？

如果这对某些人来说是一个非常明显和简单的问题,那就很难道了,但是如果你不能从一个干净的平台开始知道如何最好地开始将结构不良的代码转换为结构良好的代码,那就太难了.

Answer 1

http://en.wikipedia.org/wiki/Business_object

业务对象：一种可理解的实体，是面向对象计算机程序的 n 层体系结构中业务层内的参与者。程序可以实现类，这些类通常以管理或执行行为的对象结束，而业务对象本身通常不执行任何操作，而是保存一组实例变量或属性（也称为属性）以及与其他业务对象的关联，从而编织出一个映射代表业务关系的对象。

http://en.wikipedia.org/wiki/Business_logic_layer

业务逻辑层：业务逻辑层（BLL），也称为领域层，是一种划分的软件工程实践。在 BLL 中，对象可以进一步划分为业务流程（业务活动）和业务实体。业务流程对象通常实现控制器模式，即它们不包含数据元素，但具有协调业务实体之间交互的方法。

因此，基本上，业务对象对实体（通常是现实世界的对象，例如员工或帐户）进行建模，而业务逻辑则促进业务对象之间以及其他应用程序层之间的交互。

我认为最合适的答案是Daniel Hilgarth给出的。他的答案是不要将业务逻辑与其对象分开，因为这会导致领域模型贫乏。

虽然我认为 Paul S Patterson 提出的以下 WPF MVVM 解决方案结构是一个很好的结构，但我认为它并不适合所有人。

http://www.paulspatterson.com/technology/dot-net-development/mvvm-and-wpf-for-vb-net-series-2-part-1-again/

如果您的业务对象是数据传输对象 (DTO)（例如 Linq to SQL），而不是更复杂的对象（例如与业务逻辑可能具有更紧密耦合的组合），那么创建不同的业务逻辑和业务对象项目可能效果最佳。