好的，这是给你们的另一个:
我开始进入 n 层应用程序世界。我已经阅读了一些有关该主题的文章，一般建议是 n 层应用程序的目标是抽象层间功能。因此，基于此，在 n 层应用程序中，常规模型为:
数据访问 -> 业务层 -> 表示
由于我是一名 .NET 开发人员，我认为要增强与多种客户端类型(Silverlight、Web 应用程序甚至 WinForms 客户端)的集成，我应该使用 WCF(Windows Communication Foundation)作为业务层的数据服务，因此无论其类型如何，客户端都可以与其通信。另外，我是 NHibernate 作为 ORM 的 super 粉丝。所以我的结构是这样的:
数据访问 (NHibernate) -> 业务层 (WCF) -> 表示(WPF、ASP.NET、WinForms)
好的，这就是设置。我是这种方法的新手，所以我想我可以在这里发帖寻求有关此设置的建议。另外，我对如何在 VS 解决方案中设置它感到很困惑，我喜欢在不同的项目中分离层，但是数据对象(如客户、订单等)的抽象呢？我要把它们放在一个单独的库中吗？那么 WCF 呢？我知道通过网络将数据类传输到客户端是程序员的罪过。专业人士如何实现这一目标？
谢谢，如有任何建议，我们将不胜感激。
最佳答案
这非常符合目标。然而，N-Tier 比 N-Layer 复杂一点，可以通过询问“您的层实际上是在单独的物理服务器上吗？”来对比。
根据您的业务层的复杂程度，您可能希望在业务层和服务层之间进一步抽象它。通常，这两者联系非常紧密，并且位于同一台物理服务器上。服务层通常充当您的 BLL 的门面。
如果您的表示层位于同一台服务器上，那么您的 ASP.NET 或 WinForms 应用程序可能希望在不通过 WCF 服务的情况下与 BLL 进行通信。
继续阅读 Microsoft Patterns & Practices - Application Architecture Guide。
您的域对象应该存在于它们自己的程序集中，通常是您的域模型。根据 Microsoft Framework Design Guidelines 的说法，相应地命名项目程序集是一种很好的做法:
[公司].[产品或组件].[...]
我碰巧喜欢这种命名空间的格式，通常使用:
[公司].[产品].[层].[子层].[...]
这是一个使用解决方案文件夹来组织每个项目的示例解决方案:
在这个例子中，我有一个 BLL 和服务层。服务层在 WCF 库中提供实际实现，而演示文稿实际上包含用于托管服务的 WCF Web 应用程序。将实现与接口(interface)分开总是好的做法。
/Client 文件夹可以忽略，我只是将其用作测试的示例控制台应用程序。任何使用您的服务的客户端应用程序都应该有自己的解决方案，否则您将要管理一个庞大的解决方案。
至于通过网络传输的数据对象...我假设您指的是 ORM 中的类。 (域模型)你是正确的，它通常被认为是不好的做法。解决方案是使用数据传输对象。你可以从图片中看到我有一个.Dto 库。如果您能够使用像 AutoMapper 这样的工具，那么我完全赞成，但是，将 DTO 添加到您的解决方案会带来更多的复杂性和维护。我相信 Dino Esposito 写了一篇关于这个主题的好文章。会尽力为您找到它。
希望这对您有所帮助。
[编辑]
我应该指出，我不熟悉 nHibernate 的功能。使用该 ORM 可能有更好的解决方案。我只使用过 Entity Framework 。
[编辑 2]
查看 Dino Esposito 的 - The Pros and Cons of Data Transfer Objects
关于c# - 给新手关于 N 层应用程序的建议，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4484081/