【发布时间】：2012-03-19 11:45:18
【问题描述】：
我正在尝试根据最佳实践来构建我的 WPF MVVM 应用程序。我必须从大量现有代码开始，因此无法立即解决所有结构缺陷。我喜欢下面的解决方案结构。
这将解决方案分为以下项目； 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 类将是一个业务对象，但将它们放在不同的项目中将是一种循环依赖。 SizeChart 类是业务逻辑还是业务对象？如果我采用这个提议的 MVVM 解决方案结构，SizeChart 类应该驻留在解决方案结构中的什么位置？
如果这对某些人来说是一个非常明显和简单的问题，我们深表歉意，但是当您无法从头开始时，很难知道如何最好地开始将结构不佳的代码转换为结构良好的代码。
【问题讨论】：
-
我认为将业务逻辑与其对象分离不是一个好主意，因为这会导致anemic domain model。