关于N层应用的新手的建议
好的人，这是你的另一个：
我是从n层应用程序世界开始的。 我已经对这个主题做了一些阅读，一般建议是n层应用程序的目标是抽象层间的function。 因此，基于此，在n层应用程序中，常规模型是：
Data Access -> Business Layer -> Presentation
由于我是.NET开发人员，我认为要增强与多种客户端类型（Silverlight，Web应用程序甚至WinForms客户端）的集成，我应该使用WCF（Windows Communication Foundation）作为业务层的数据服务，以便客户端可以进行通信无论其类型如何。 另外，作为ORM，我是NHibernate的忠实粉丝。 所以我的结构是这样的：
Data Access (NHibernate) -> Business Layer (WCF) -> Presentation (WPF, ASP.NET, WinForms
好的，这就是设置。 我是这种方法的新手，所以我想我可以在这里发帖请求有关此设置的建议。 另外，我对如何在VS解决方案中设置它感到困惑，我喜欢在不同的项目中分离层，但是对于数据对象的抽象（如Customer，Order等）呢？ 我把em放在一个单独的库中吗？ 那么WCF呢？ 我知道通过线路将数据类传输到客户端是一个程序员的罪。 专业人士实现这一目标的方式是什么？
谢谢，任何建议将非常感谢。
这几乎是目标。 然而，N-Tier比N-Layer复杂一点，可以通过询问“你的层实际上是否存在于不同的物理服务器上”来形成对比？
根据业务层的复杂程度，您可能希望在业务层和服务层之间进一步抽象。 通常，这两者紧密相连，并且位于同一物理服务器上。 服务层通常充当BLL的Facade。
如果您的Presentation层位于同一台服务器上，那么您的ASP.NET或WinForms应用程序可能希望在不通过WCF服务的情况下与BLL通信。
阅读Microsoft模式与实践 – 应用程序架构指南 。
您的域对象应该位于他们自己的程序集中，通常是您的域模型。 根据Microsoft框架设计指南 ，最好相应地命名项目程序集：
[公司]。[ProductOrComponent]。[…]
我碰巧喜欢这种名称间距的格式，一般使用：
[公司]。[产品]。[层]。[子]。[…]
以下是使用解决方案文件夹组织每个项目的示例解决方案： 
在这个例子中，我有一个BLL和服务层。 Service层在WCF库中提供实际实现，而Presentation实际上包含用于托管服务的WCF Web应用程序。 从界面中分离实现总是很好的做法。
可以忽略/ Client文件夹，我只是将其用作测试的示例控制台应用程序。 任何使用您服务的客户端应用程序都应该有自己的解决方案，或者您将要管理一个巨大的解决方案。
至于您通过网络传输的数据对象……我假设您的意思是ORM中的类。 （领域模型）你是正确的，它通常被认为是不好的做法。 解决方案是使用数据传输对象。 你可以从图片中看到我有一个.Dto库。 如果你能够使用像AutoMapper这样的工具，那么我就可以将它添加到你的解决方案中，从而带来更多的复杂性和维护。 我相信Dino Esposito写了一篇关于这个主题的好文章。 会试着为你找到它。
希望这可以帮助。
[编辑]
我应该注意，我不熟悉nHibernate的function。 使用该ORM可能有更好的解决方案。 我只使用过Entity Framework。
[编辑2]
查看Dino Esposito的 – 数据传输对象的优缺点