好的，各位，这是给你们的另一篇：
我开始涉足 n 层应用程序世界。我已经阅读了一些有关该主题的内容，一般建议是 n 层应用程序的目标是抽象层间功能。因此，基于此，在 n 层应用程序中，常规模型是：
Data Access -> Business Layer -> Presentation
由于我是一名 .NET 开发人员，我认为为了增强与多种客户端类型（Silverlight、Web 应用程序甚至 WinForms 客户端）的集成，我应该使用 WCF（Windows Communication Foundation）作为业务层的数据服务，以便客户端可以进行通信无论其类型如何。另外，我非常喜欢 NHibernate 作为 ORM。所以我的结构是这样的：
Data Access (NHibernate) -> Business Layer (WCF) -> Presentation (WPF, ASP.NET, WinForms
好的，这就是设置。我是这种方法的新手，所以我想我可以在这里发帖请求有关此设置的建议。另外，我对如何在 VS 解决方案中设置它感到非常困惑，我喜欢在不同的项目中分离层，但是数据对象的抽象（如客户、订单等）呢？我要把它们放在一个单独的库中吗？那么 WCF 呢？我知道通过线路将数据类传输到客户端是程序员的罪过。专业人士的方法是什么？
谢谢，任何建议将不胜感激。
这几乎达到了目标。然而，N-Tier 比 N-Layer 稍微复杂一些，可以通过询问“您的层实际上位于单独的物理服务器上吗？”来进行对比。
根据业务层的复杂程度，您可能希望在业务层和服务层之间进一步抽象它。通常，这两者紧密相连并位于同一物理服务器上。服务层通常充当 BLL 的外观。
如果表示层位于同一服务器上，则 ASP.NET 或 WinForms 应用程序可能希望与 BLL 进行通信，而不通过 WCF 服务。
继续阅读Microsoft 模式与实践 - 应用程序架构指南 http://apparchguide.codeplex.com/.
您的域对象应该存在于它们自己的程序集中，通常是您的域模型。根据微软框架设计指南 https://rads.stackoverflow.com/amzn/click/com/0321545613，最好相应地命名您的项目程序集：
[公司].[产品或组件].[...]
我碰巧喜欢这种名称间距格式并且通常使用：
[公司].[产品].[图层].[子图层].[...]
Here is an example solution using solution folders to organize each project:
在此示例中，我有一个 BLL 和服务层。服务层提供 WCF 库中的实际实现，而演示文稿实际上包含托管服务的 WCF Web 应用程序。将实现与接口分开始终是一个好习惯。
/Client 文件夹可以忽略，我只是将其用作示例控制台应用程序进行测试。任何使用您的服务的客户端应用程序都应该有自己的解决方案，否则您将管理一个巨大的解决方案。
至于通过网络传输的数据对象...我假设您指的是 ORM 中的类。 （域模型）您是正确的，它通常被认为是不好的做法。解决方案是使用数据传输对象。你可以从图片中看到我有一个.Dto库。如果您能够使用像 AutoMapper 这样的工具，那么我完全支持它，但是，将 DTO 添加到您的解决方案中会带来进一步的复杂性和维护。我相信迪诺·埃斯波西托（Dino Esposito）就这个主题写了一篇很好的文章。将尽力为您找到它。
希望这可以帮助。
[EDIT]
我应该指出，我不熟悉 nHibernate 的功能。使用 ORM 可能有更好的解决方案。我只使用过实体框架。
[EDIT 2]
看看迪诺·埃斯波西托的 -数据传输对象的优点和缺点 http://msdn.microsoft.com/en-us/magazine/ee236638.aspx
