关于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模式与实践 - 应用程序架构指南.

您的域对象应该位于他们自己的程序集中,通常是您的域模型.根据Microsoft框架设计指南,最好相应地命名项目程序集:

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

我碰巧喜欢这种名称间距格式,一般使用:

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

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

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

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

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

希望这可以帮助.

[编辑]

我应该注意,我不熟悉nHibernate的功能.使用该ORM可能有更好的解决方案.我只使用过Entity Framework.

[编辑2]

查看Dino Esposito的 - 数据传输对象的优缺点