WPF 应用程序中的业务逻辑放置

Question

这可能是一长串问题，但请多多包涵。我开始使用 WPF、PRISM、CODE FIRST 和 SQL CE 构建 LOB 应用程序，在我的第一个应用程序（或尝试）之后，我有很多问题，所以首先：

1. 业务逻辑应该放在哪里，在模型中还是在域层之上的 BLL 层中？
2. 视图模型应该接收对存储库的引用还是应该仅由域模型对象使用存储库？
3. 换一种方式说第二个问题，应该给视图模型什么样的对象？
4. 我在显示中（例如在数据网格中）和在表单中编辑时使用相同的视图模型，但这会带来很多麻烦，有没有更好的方法来做到这一点而无需重复代码？
5. 我面临的最大问题是，我总是以层次关系组织视图模型，不允许层次结构中的子级获取对其父级的引用，并且由于视图绑定到这些子级并调用导致添加的方法对存储库的对象我找不到一种方法来通知父母对这些存储库的更改。所以绑定视图可以更新，我看到有些人使用事件解决了这个问题，但我不喜欢这个解决方案，我想知道是否有更好的方法来做到这一点？
6. 谁能指出使用上述技术构建实际 LOB 应用程序的示例，至少不是使用 VB .NET 或 WCF 的示例（我想要本地数据库）。

Answer 1

我现在正在使用 WPF、Entity Framework Code First 和带有本地数据库的 SQL CE 4.0 开发 LOB 应用程序。我没有使用 PRISM，但我使用 MEF 作为 IoC 和我自己的实现。

1. 到目前为止，我建议您使用 Code-First 方法的优势并在您的域类中实现尽可能多的业务逻辑。还要在其中实施 INPC。如果不这样做，您最终会在 ViewModel 中复制所有属性，这是无稽之谈。没有规定模型应该是愚蠢的（尽管有些人倾向于这样认为），但是愚蠢的模型只会让 ViewModel 使用起来更加乏味。
2. 如果不了解您的项目，这里没有明确的建议，但有常识：尽量坚持最佳实践，除非它们开始妨碍您。 “完美”往往是“好”的敌人。
3. 让 ViewModel 获得他们需要的任何东西（单个模型对象、集合等）来为您的视图提供服务。从长远来看，更简单的解决方案通常更易于维护。
4. 我不太明白你的意思...如果可能的话，我会多次使用我的 ViewModel，但如果你在尝试让一个 VM 工作时遇到问题，我认为 ViewModel 的功能是服务于一个视图对于多个视图，您可能需要将其分成两个不同的 VM。只需在一个基类中收集所有常见的属性和方法，并根据需要从它继承。
5. VM 之间有一些松散耦合的方式来相互通信。我正在为此类事情使用 MVVM Light Messenger 类，但我知道 PRISM 提供了类似的功能。如果您不滥用它，那么从孩子中引用父母并不是一种罪过。我有一个 ViewModelBase 并且孩子有一个指向基类并指定 T 类型的父引用，这是迄今为止硬引用和松散引用之间的良好平衡。
6. 如果有人向您指出这样的例子，请告诉我！实际上，使用本地数据库应该更简单。在我的情况下，我使用的是单例上下文（很多人似乎讨厌它），但由于这是一个本地应用程序，只有一个用户并且没有线程复杂性，所以单例上下文使我的生活更轻松。在这种情况下，我仍在等待找到一个不这样做的真正充分理由。

PS：有些人可能会否决您的问题，因为...这不是一个问题，它为大量辩论开辟了空间。如果它被关闭，请尝试聊天。

希望对您有所帮助，问候！