ASP.Net MVC 4和.Net 4.5项目解决方案结构



我已经开始从事新的企业项目,平台ASP.Net MVC 4,jQuery,Knockout,.Net 4.5,WCF,工作流,业务规则等,我正在努力寻找我可以为创建整个项目的解决方案而受益的好的参考。经过我自己的研究(谷歌,stackoverflow和许多其他博客),下面是我创建的解决方案。然而,我仍然不确定我所创建的是不是遵循了最佳实践,并在未来几年内采用新的平台和业务变化。

一个解决方案(6个项目)

Solution(ProjectName)
Web(Having MVC 4 project template, added many script reference thru Nuget like      jQuery, knockout etc.,), IOC Container(Castle Windsor)

DTO-

ServiceManager(WCF 4.5)
Core
Business Rules
Workflow
Domain Objects
Common
Logging - ILog
Caching - HttpCache
Security - Custom
DAL
Repository 
Unit of Work
Other Data Base like DB2, Oracle

这是的序列

Web Layer --> call to DTO ( Request/Response skelton) --> Service Manager(WCF) --> Core(Business Rules, Workflow flow etc) --> DAL.

跨层添加的通用项目。

请提出任何好的设计模式来实现内部和外部。例如,对服务进行Web调用的有效方式、代理通道、分布式事务、连接不同的数据源。

现在我有两个不同的数据库,一个是SQL Serer,另一个是DB2托管的一个大型机。DAL项目我添加了EF来处理基于SQL的事务。DB2我添加了OLEDB瘦驱动程序。我需要一些设计模式,如何根据请求将调用者路由到不同的源。

此外,我还需要一些关于依赖注入和IOC框架的好建议。我已经决定使用castle windsor(我看过NInjuct、Spring.Net、Autofac),但仍然不确定缺点。

非常感谢您对此标签的指导和建议。

如果我是你,我从一开始就不会创建那么多层。我想说的是从一些基本的东西开始,然后边做边扩展。

没有真正的最佳实践,一切都取决于你的项目。不过,总的来说,我发现在需要时添加一层,然后再移除一层更容易。如果你看到自己的呼叫只是通过一个层,那么你就很好地表明你的层太多了。

至于依赖项注入,您可以使用您提到的任何一个容器,它们都具有类似的功能。就我个人而言,我更喜欢Ninject,但这是品味的问题。DI容器的一个缺点是,由于耦合松散(如果使用正确的话),导航代码可能会变得有点困难。Resharper对此帮助很大。

从我所看到的,你有一个非常厚的服务层,它包含了所有的域逻辑,此外还有很多只有属性的类(所有层的公共项目)。这就是所谓的贫血模型,一些人认为这是一种反模式(尽管它通常做得很好)。另一种方法是DDD,在DDD中对相同类的行为和状态进行建模。在我看来,如果你也应用CQRS,效果最好。(命令查询职责分离)

如果你对这种方法感兴趣,我写了一本关于DDD、CQRS和事件来源的介绍,你可以查看。欲了解更多信息,请查看Greg Young和Udi Dahan 的所有信息

最新更新