关于N层应用的新手的建议

Question

好的人，这是你的另一个：

我从n层应用程序世界开始。我已经对这个主题做了一些阅读，一般的建议是n层应用程序的目标是抽象层间的功能。因此，基于此，在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呢？我知道通过线路将数据类传输到客户端是一个程序员的罪。专业人士实现这一目标的方式是什么？

谢谢，任何建议都将非常感谢。

Answer 1

这几乎是针对目标的。然而，N-Tier比N-Layer复杂一点，可以通过询问“你的层实际上是否存在于不同的物理服务器上来对比？”来对比。

根据业务层的复杂程度，您可能希望在业务层和服务层之间进一步抽象。通常，这两者紧密相连，并且位于同一物理服务器上。服务层通常充当BLL的Facade。

如果您的Presentation层位于同一台服务器上，那么您的ASP.NET或WinForms应用程序可能希望在不通过WCF服务的情况下与BLL通信。

阅读Microsoft Patterns & Practices - Application Architecture Guide。

您的域对象应该位于自己的程序集中，通常是您的域模型。根据{{​​3}}，最好相应地命名项目程序集：

[公司]。[ProductOrComponent]。[...]

我碰巧喜欢这种名称间距格式，通常使用：

[公司]。[产品]。[层]。[子层]。[...]

以下是使用解决方案文件夹组织每个项目的示例解决方案：

在这个例子中，我有一个BLL和服务层。 Service层在WCF库中提供实际实现，而Presentation实际上包含用于托管服务的WCF Web应用程序。从界面中分离实现总是很好的做法。

可以忽略/ Client文件夹，我只是将其用作测试的示例控制台应用程序。任何使用您服务的客户端应用程序应该都有自己的解决方案，或者您将要管理一个巨大的解决方案。

关于通过网络传输的数据对象......我假设您的意思是ORM中的类。 （领域模型）你是正确的，它通常被认为是不好的做法。解决方案是使用数据传输对象。你可以从图片中看到我有一个.Dto库。如果你能够使用像AutoMapper这样的工具，那么，我只需要它就可以了，将DTO添加到你的解决方案中会带来更多的复杂性和维护。我相信Dino Esposito写了一篇关于这个主题的好文章。会试着为你找到它。

希望这有帮助。

---

<强> [编辑]

我应该注意，我不熟悉nHibernate的功能。使用该ORM可能有更好的解决方案。我只使用过实体框架。

---

[编辑2]

查看Dino Esposito的 - Microsoft Framework Design Guidelines