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容器注入的应用程序组件）。

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

What are Business Objects and what is 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层架构中业务层内的actor。虽然程序可以实现类，这些类通常以管理或执行行为的对象结束，但业务对象本身通常不执行任何操作，但拥有一组实例变量或属性，也称为属性，以及与其他业务对象的关联，编织映射表示业务关系的对象。

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

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

基本上，业务对象模拟实体（通常是真实世界对象，如Employee或Account），而业务逻辑则促进业务对象之间以及其他应用程序层之间的交互。

我认为Daniel Hilgarth给出了最合适的答案。他的回答是不要将业务逻辑与其对象分开，因为这会导致anemic domain model。

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

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

如果您的业务对象是Data Transfer Objects (DTOs)，那么创建不同的业务逻辑和业务对象项目可能效果最佳。 Linq to SQL而不是更复杂的对象，例如可能与业务逻辑具有更紧密耦合的复合对象。

Answer 2

业务对象是一个相当无定形的术语 - 它是DTO，POCO还是混合了一些业务逻辑？

对我来说，我会考虑不同的东西 - Chart和SizeChart都是控件而不是“业务对象”或“业务逻辑”。事实并非他们在其中具有UI探测功能名称，而是他们实际上在做UI或渲染相关工作（尺寸和绘图）。这些处理的数据集合将是独立的，并在调用Size或Draw之前分配给控件。

请注意，这个答案与MVVM无关，因为它有点像红色鲱鱼 - 你的问题与一般的n层设计更密切相关，在这种设计中你也融入了MVVM。

Answer 3

我最近在一个项目上碰到了类似的东西。

我们有一个网络应用程序，允许管理员创建组。所需的规则之一是您无法创建两个同名的组。我们最终做的是创建一个非常基本的对象，一个组，然后创建一个名为GroupService的服务。 GroupService执行规则检查，以便当用户调用GroupService.Save（Group）时，该服务将熄灭并检查具有该名称的先前组。如果找到该名称，则会向用户返回错误，并且不会进行保存。

在我们的示例中，层次结构是Controller具有服务，服务具有存储库，而存储库最终提交到数据库。在这些抽象中运行的是模型Group。但我们的模型不仅仅是一个“愚蠢”的对象。它确实包含数据字段本身的验证逻辑，并具有聚合属性以简化数据绑定。

将此扩展到MVVM conecept，我认为View Model将拥有包含业务逻辑的服务以及要合并到View中的模型。显然，View将绑定到ViewModel，但ViewModel会有一些要绑定的Model对象的实例。

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

3 个答案: