使用WPF&；的业务应用程序的最佳体系结构是什么；EF？

我对我们可以使用WPF 4.0和EF 4.0技术开发业务应用程序的体系结构感到困惑

我的第一个选择是传统的N层体系结构，它包含：UI、业务逻辑层和数据访问层，具有断开连接的行为

通过这种方式，我为每个层创建了3个项目，为我的实体/DTO创建了另一个项目（每个层都是一个程序集）。每个层只引用它的上层和下层（即：UI可以看到BLL，但看不到DAL）。但出于通信目的，所有层都可以访问实体/DTOs程序集。 例如，当我想用DataGrid创建一个简单的CRUD表单时，问题就开始了。BLL在返回实体/DTO时处理DAL的DataContext，这就是迫使我使用STE的原因。但也存在一些问题。例如，我应该为从BLL返回到UI的每个实体调用“StartTracking”方法。简而言之，我不确定这种模式的可靠性，或者我认为我必须忘记自动处理的CRUD表单

我在DAL层中使用了存储库模型，但当我搜索存储库模式时，我发现它有所不同。从UI中引用DAL/存储库和BLL/服务（不是WCF或WebServices）层似乎不错，因此我们可以拥有一个连接的环境（不使用STE）

我看到一个示例，其中我们可以从存储库中获取一个人，但可以使用BLL或服务对其进行操作：

用户界面代码：

var person = new PersonRepository().GetPerson(10);
Bll.Salary.PaySalary(person);

-或-

或者类似的事情

使用此模式，我们可以在DataContext处于活动状态时以连接方式将实体/DTO发送到UI

我不知道我是否了解在大型项目中使用存储库模式的方法。我认为以这种方式命名BLL或服务类和方法并不清楚。开发人员可能会对在何处使用存储库方法或BLL/服务方法或在何处创建方法（在存储库或BLL/服务中）感到困惑

我更喜欢N层体系结构，它使用一种很好的方法来自动跟踪实体/DTO的变化，就像STE一样

---

请您推荐这种情况下的最佳模式，或者/并让我参考一些关于这方面的好书或文档。

我制作了一个示例应用程序，可以帮助您解答一些问题。您可以通过我的博客文章查看演示文稿和示例：

该示例显示如何使用STE，并包括一些帮助程序，以使实体框架STE在桌面客户端应用程序中更好地工作

存储库用于隐藏获取数据的详细信息。其想法是，您可以将存储库的实现从使用本地数据库的存储库切换到使用远程web服务的存储库，而不让上层知道它。

本文可能对您有所帮助

---

您还可以查看的BookLibrary示例应用程序。它显示了一个WPF MVVM应用程序以及应用所述体系结构的实体框架。

感谢您的示例。我查一下，然后答复。关于存储库，我和你一样认为，但正如我所说，它似乎可以是不同的！如果您对样品有任何疑问，请告诉我。它基于一个真实世界的WPF应用程序，我在过去的一年里一直在开发这个应用程序。就存储库的内容而言，关于如何做到这一点，肯定有很多想法。我认为在有效的东西和理论上“纯粹”但难以理解的东西之间取得平衡是很重要的。过于抽象会使事情变得很难理解。找到对你有意义的东西，然后去做。主要目标是“分离关注点”。非常感谢，这是一个很好的示例！但它的业务逻辑在哪里？我们的项目中有大量的业务逻辑，这是我管理的问题。虽然我仍然问我的问题；我可以引用n层应用程序中需要的任何层，还是应该使用其他模式？我正在寻找一个好的n层业务模式。将业务逻辑放在何处的问题在很大程度上取决于您的场景。我认为有很多似是而非的答案。如果需要，您可以将其放在中间层（服务器）上。然而，对于响应速度最快、内容最丰富的交互，您可能需要客户机上的部分/全部。在这种情况下，您可以在模型中放置逻辑：-（请参阅域驱动设计/DDD）。无论模型的状态如何，这都适用于始终为真的规则。但不适用于基于工作流的规则。-在视图模型中。对于规则来说，这是一个不错的地方，但将其重用限制在使用该视图模型的视图中。-在“服务层”中。说到服务，我指的不是web服务，而是一个库。

var person = new PersonRepository().GetPerson(10);
Bll.Person.MarkAsAbsent(person);