我正在尝试根据最佳实践来构造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容器注入(inject)的应用程序组件)。
我理解业务对象代表人类世界实体，而业务逻辑是此问题中讨论的实现细节。
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类将是业务对象，但是将它们放置在不同的项目中将是循环依赖项。 SizeChart类是业务逻辑还是业务对象？如果采用此建议的MVVM解决方案结构，SizeChart类应位于解决方案结构中的什么位置？
道歉，如果这对某些人来说是一个非常明显和简单的问题，但是当您无法从头开始时就很难知道如何最好地开始将结构不良的代码过渡到结构良好的代码，这很困难。
最佳答案
http://en.wikipedia.org/wiki/Business_object
业务对象:一种可理解的实体，是面向对象的计算机程序的n层体系结构中业务层内部的参与者。
程序可以实现类，这些类通常以管理或执行行为的对象结尾，而业务对象通常不执行任何操作，而是保留一组实例变量或属性(也称为属性)以及与其他业务对象的关联，从而编织一个代表业务关系的对象。
http://en.wikipedia.org/wiki/Business_logic_layer
业务逻辑层:业务逻辑层(BLL)，也称为域层，是分隔的软件工程实践。
在BLL中，对象可以进一步划分为业务流程(业务事件)和业务实体。业务流程对象通常实现 Controller 模式，即它们不包含数据元素，但具有协调业务实体之间交互的方法。
因此，基本上，业务对象对实体(通常是诸如雇员或客户之类的现实世界对象)进行建模，而业务逻辑则促进了业务对象之间以及其他应用程序层之间的交互。
我认为最合适的答案是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，而不是更复杂的对象(如可能更紧密耦合到业务逻辑的复合对象)。
关于c# - 业务对象和业务逻辑之间有什么区别，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/9769557/