.Net项目分层与文件夹结构大全(最佳架子奖,吐槽奖,阴沟翻船奖揭晓)

浪人

　　
　　一个装X的架构师，通过建文件夹就能亮瞎你的狗眼...
　　——传说中的弦哥
　　目前为止,最佳架子奖：  圣殿骑士！！！
　　评选理由：
　　老油条了，没啥好说的....分层的描述很准确。
　　特别是WebModel(ViewModel)的理解和描述很到位，避免了搞ViewModel的设计过渡之嫌，如果你有设计ViewModel的话....
　　可惜缺乏对数据访问层的描述，不知道会不会阴沟里翻船...

　　01，User Interface即UI层：该层作为数据输入和展示的界面，是与用户交互的有效途径，所以它起着至关重要的作用。往往给人第一印象的就是UI层，在设计的时候也要根据不同的技术或者不同的要求进行斟酌。通常可以把UI分为B/S UI、C/S UI以及WEB服务。在这里就是我们的ASP.NET项目。
　　02，WebModelCommon：这层作为UI与领域逻辑的中间层，它的充当了桥梁、筛选、过滤和验证的作用。它主要包括两个工程，WebHelper主要提供给UI一些常用操作。WebLogic主要对UI与领域逻辑的数据进行转换、筛选、验证及过滤操作。
　　03，Business Logic：Domain Model （Data Model Layer）始终是应用程序的核心，必须投入大量精力，按照面向对象的分析和设计 (OOAD) 最佳做法进行设计同时按照OOP进行开发。
　　04，FrameWork：主要包括数据访问框架、通用权限框架、异常和日志处理框架、IOC框架、AOP框架等基础或常用功能。
　　05，SOA：这一层不是必须的，根据项目的具体情况进行取舍，如果业务比较复杂且交互项目繁多，那么SOA可以减轻我们的负担；如果业务比较单一且相对简单，就可以直接调用或者使用Web Service/Remoting/WCF作为通信框架即可。在实施SOA的过程中，可以自己使用WCF+WF搭建一个小型轻量级的SOA框架，也可以使用诸如Biztalk等软件。
　　06，Reference：这里主要包括第三方的框架和组件项目，把这些文件分门别类地集中放在此目录下。
　　07，Solution Items：项目的规范、流程、重要文件等。
　　08，Test：这里主要放置测试需要的一些信息，如测试版本、测试文档等。
　　09，Publish：这个文件夹主要放置发布的版本。
　　作者的获奖感言：比较关心有没有奖品？ 其实这个架构比较复杂一点（考虑到经常扩展和升级），如果小项目，就没有必要这么折腾了。当时是支持多国家、多设备，比如同样的项目可以在新加坡和美国根据IP的不同来自动寻址访问，同时根据设备的不同而又有两套路径，手机用户导航到手机网站页面，PC用户就到正常页面。关于数据访问层，有一个适配器，可以通过配置选择ORM（自己写的一套类库，封装在Framework里面）还是经典方式（SQL和存储过程等全部单独写在XML文件里面，通过读取XML文件进行调用，这样维护和版本升级比较方便，同时为了降低系统的负载同时提高用户的响应能力，我们采用了MSMQ和SSB来组织消息队列）。另外数据层都有Mock data for testing，这样就能保证项目扩展和升级造成的相互依赖而耗费过多的时间和精力。如果有时间，可以写一篇文章出来大家探讨！
　　回复感言：
　　奖品是必须的，针对此架构写一篇详细的文章，并附上源码。
　　小项目确实没必要搞这么复杂，可以参考帖子里的“土鳖实战派”，那个分层我觉得就挺实在的。
　　Mock data for testing是个好办法，有空介绍些好的Mock框架。
　　最佳吐槽奖： [秦时明月] ！！！
　　他只在评论里淡淡的回复了一句：“其实我只想说一点:大家都乱了.”。轻轻的来，不留一片架子。不过弦哥是不会放过他的......
　　于是乎弦哥到他的博客http://www.cnblogs.com/humble/里搜刮了一番，发现了他其实也有架子，“Moon.ORM”,“Qin.Data”（和秦时明月这个名字遥相呼应，文艺青年哈）......
　　其实我想说的是， 无论是所谓“大道至简”的秦时明月，还是主流的圣殿骑士，单从技术实现来说可以说条条大路通罗马...无所谓对错...
　　但在现实中圣殿骑士的路子可以上的台面去企业做培训，而秦时明月可能更多的是孤芳自赏，其中缘由，大家可以探讨...
　　
　　 阴沟翻船奖 Artech：

作者描述：我在《WCF全面解析》中的一个实例的解决方法结构，基本思路是：先模块（这里指粗粒度模块，可以看成子系统）（两个业务模块：Products、Orders，一个非业务模块：Infrastructure），后层次。 Products.BusinessEntity：提供的业务实体（Business Entity）类型的定义。一般来讲，业务实体和数据契约是不同的，在这里为了简单起见，我们不仅仅将二者合一，还将业务实体作为ASP.NET MVC的Model使用； Products.DataAccess：数据访问层，在这里单纯地提供对数据库的访问了。该项目具有针对Products.BusinessEntity的项目引用； Products.BusinessComponent：也可以称为业务逻辑层，真正的业务逻辑实现 在这里。该项目具有针对Products.BusinessEntity和Products.DataAccess的项目引用； Products.Service.Interface：WCF服务的契约接口定义在这里。该项目具有针对Products.BusinessEntity的项目引用； Products.Service：用于定义实现了上述契约接口的服务。该项目具有针对Products.Service.Interface 、Products.BusinessEntity和Products.BusinessComponent的项目引用； Products：为本模块提供基本的功能，不仅仅包含对服务的调用，也包括一些必要的逻辑处理。该项目具有针对Products.BusinessEntity、Products.Service.Interface和Products.Interface的项目引用； Products.Interface：模块提供给其他模块的服务接口。该项目具有针对Products.BusinessEntity的项目引用。

点评：Artech算是园子里的大佬，貌似还出了书，不过发的这个架子有点出乎我意料，存在有一些值得商榷的问题：
1.从架子中的命名和大体结构明显看出是走的DDD,在DDD中数据访问的具体实现(就是夹子里的DataAccess)应该是放在基础设施层（就是夹子里的Infrastructure），而Artech却貌似只把Infrastructure作为了"非功能性需求"的Framework去用。并把Infrastructure叫“非业务模块”，显得有些外行....
2.Products.BusinessComponent业务逻辑层 直接引用了Products.DataAccess，这也是个严重的问题，如果DataAccess是没有接口的，那么业务逻辑层依赖数据访问层，在DDD和马丁大叔的企业架构设计中，是一个反模式！！！，如果DataAccess里有接口，那么，DataAccess的接口应该是放在业务逻辑层的，然后通过依赖反转去用，而DataAccess的具体实现是放在Infrastructure里的。
3.如果没有用WCF，那么我认可可以省略掉DTO，但架子里上的WCF,还把DTO和PO合二为一，这个我非常不赞同。
4.Products层和Products.BusinessComponent层边界不清晰，按Artech描述 ，两个层里都可以放业务逻辑，但描述的模棱两块。而且基本可以看出Products.BusinessEntity又还是失血模型，这个设计完全让人摸不着头脑。Products层我猜是有点DDD中Application层的意思，但Artech明显做的不对。
总之我感觉这个架子，装的成分比较大，思路十分不清晰，命名很不规范，有失水准。

作者的获奖感言：谢谢给我这个奖：） 1. 我的这个结构主要考虑的是模块化，而不是层次化。或者在模块的基础上划分层次。 2. 模块是以功能为主，模块封装业务功能和非业务功能。我主张在模块级别对外提供服务，而不是层次上对外提供服务。 3、层次是模块为了实现自身功能而进行的层次划分，所以没有必要为每一个层次定义接口。DataAccess提供接口的一个很大的目的在于隔离数据存储，是对多种数据存储方式的支持。实际上很多类似与DbHelper就能够提供这样的功能。所以我很不喜欢为DataAccess定义接口，虽然PetShop是这样做的，很多项目也是这样做的，我依然觉得很丑。 4、接口是是契约，是“服务”的接口，只有在对外提供服务的情况下需要定义接口。而一个模块为另一个模块提供服务，才需要定义接口。 5、由于采用了WCF，我们采用了SO的 设计，即在通过WCF服务的方式提供一种理想的功能共享的粒度，而Business是实现服务的方式，它和Service之间不需要太强的松耦合，不要忘了Service采用暴露在外的，并且采用Service Contract的方式进行服务消费的。 6、...

回复感言：
1.搭架子的核心是层次的划分，功能模块(包)的划分并不是关键；
2.业务逻辑层如果对存储层（DataAccess）有依赖，是无法达到隔离数据存储的目的的。不给存储层定义接口并采用依赖反转技术，是无法去掉业务逻辑层对存储层的依赖的，petshop是垃圾不做讨论；
3.一个模块的自我实现和对外接口的设计没有问题，但和业务逻辑无关，而是很薄的一个接口；
4.真正实现SOA的粗粒度服务，在自己的架子级别其实是无法实现的，更多的是靠大厂商SOA的中间件产品。用了WCF就叫SOA啦？

另：感谢Artech在WCF方面的贡献，话说我当年看WCF还费劲呢，也是看了你的帖子才豁然开朗。　　我先来抛砖引玉：
　　传说中的弦哥:

　　tips：
　　1."解决方案文件夹"能帮助你很好的规划项目结构
　　2.通过对"解决方案文件夹"前面加数字1,2,3,4....，能让项目按你想要的顺序排序
　　3.公司名.项目名.包名.架构名的命名空间 命名约定能让你的项目结构更清晰
　　4.分项目的多少还是要根据项目具体情况和架构设计,分太多编译速度慢不说,其实用起来也麻烦
　　一晴 ：

　　点评:一个比较简单的博客网站，用的是MVC，命名啥的还是比较规范的。
　　建议：可以把Controller和Model从网站项目中提出来
　　 xu_happy_you ：
　　
　　点评：典型的Petshop控，BLL+DAL+MODEL+网站 的三层架构，通过工厂模式来调用DAL
　　建议：可以进一步尝试DDD，并用DI依赖注入代替工厂模式
　　微软根据DDD架构做的一个分层示范项目,NLayerAppV2：

　　下载网址：http://microsoftnlayerapp.codeplex.com/workitem/6687
　　微软的一个CRM项目：

　　下载网址：http://orchard.codeplex.com/
　　点评：尼玛这分的太多了............
　　.Net下大名鼎鼎的CMS  ，DotNetNuke（DNN）：

　　下载网址：http://www.dotnetnuke.com/
　　点评：大部分我觉得挺好的，划分合理，结构清晰，就是“Providers”里面搞那么多”解决方案文件夹“搞毛啊！！！
　　臭名昭著的PetShop4.0:

　　点评：这些年来毒害了不少无知菜鸟，成就了不少装X砖家.....人家拿来和java测效率的项目，你们拿来研究架构？
　　 一线码农 ：

　　点评：此码农初窥门径，命名规范，结构合理清晰，.Test是亮点，说明已经上了DDT，值得表扬，不过说确实分的有点太细了...
　　建议：“ZhuangHuang”这个拼音立马把档次降低了，建议改成英文，装X！！！懂不！！！装潢....地可儿瑞特..decorate
　　 Jaws:

　　点评：小写和缩写的命名方式看上去有点小清新的味道，比较像java那边的习惯，说！你是不是那边来的细作！！
　　建议：CSS,JS,JSON这种有必要都分成单独的项目吗？搞的和DNN一样....
　　 道法自然：

　　点评：从各方面看，无可挑剔，相当专业。基于Plugin的设计很考验功力...........你是来砸场子的吗？！！！
　　建议：给出源码供广大童鞋学习...
　　 魂淡：

　　点评：从用英文的Visual Studio可以看出此人比我还能装...，采用WCF实现分布式架构，命名准确专业,结构清晰合理。
　　难能可贵的是形式上没有一点照猫画虎的痕迹，但又处处体现出设计和模式的思想。鉴定为高手..
　　建议：你丫签出那么多项目，别人想加文件咋整！！！
　　 刘海川：

　　点评：照猫画虎，乏善可陈
　　建议：多向楼上那位学习...从用英文Visual Studio开始！！！～～～
　　 kiler ：
　　
　　点评：土鳖实战派！！公用类+业务逻辑+数据库访问+实体+网站。分层目的明确，表达直截了当，没有丝毫多余的设计和矫揉造作的命名。
　　建议：实战之余也可多看看一些经典的设计和架构理论。
　　双击：

　　点评：做网站的屌丝，贴架子还不忘发广告....,比较好奇Component里都有些什么东东
　　项目网址：http://www.jielongdaquan.com/
　　柳柳英侠 ：
　　
　　点评：命名方面有些Petshop的遗风，但又有一些比较潮的设计思想。
　　建议：接口单独放一层值得商榷，去看看马丁大叔的依赖反转，并深入理解。
　　　　　对于Model方面分了 PO，ViewModel和DTO，是否有设计过渡之嫌？
　　林之空间:

　　点评：傍着Camstar的高帅富，DesignerClient在手，其他的都是浮云..........
　　园子里阿不同学：
　　
　　点评：从架子看，功力扎实，设计老道。但并不潮.....
　　
　　圣殿骑士：
　　
　　01，User Interface即UI层：该层作为数据输入和展示的界面，是与用户交互的有效途径，所以它起着至关重要的作用。往往给人第一印象的就是UI层，在设计的时候也要根据不同的技术或者不同的要求进行斟酌。通常可以把UI分为B/S UI、C/S UI以及WEB服务。在这里就是我们的ASP.NET项目。
　　02，WebModelCommon：这层作为UI与领域逻辑的中间层，它的充当了桥梁、筛选、过滤和验证的作用。它主要包括两个工程，WebHelper主要提供给UI一些常用操作。WebLogic主要对UI与领域逻辑的数据进行转换、筛选、验证及过滤操作。
　　03，Business Logic：Domain Model （Data Model Layer）始终是应用程序的核心，必须投入大量精力，按照面向对象的分析和设计 (OOAD) 最佳做法进行设计同时按照OOP进行开发。
　　04，FrameWork：主要包括数据访问框架、通用权限框架、异常和日志处理框架、IOC框架、AOP框架等基础或常用功能。
　　05，SOA：这一层不是必须的，根据项目的具体情况进行取舍，如果业务比较复杂且交互项目繁多，那么SOA可以减轻我们的负担；如果业务比较单一且相对简单，就可以直接调用或者使用Web Service/Remoting/WCF作为通信框架即可。在实施SOA的过程中，可以自己使用WCF+WF搭建一个小型轻量级的SOA框架，也可以使用诸如Biztalk等软件。
　　06，Reference：这里主要包括第三方的框架和组件项目，把这些文件分门别类地集中放在此目录下。
　　07，Solution Items：项目的规范、流程、重要文件等。
　　08，Test：这里主要放置测试需要的一些信息，如测试版本、测试文档等。
　　09，Publish：这个文件夹主要放置发布的版本。
　　点评：老油条了，没啥好说的....分层的描述很准确。
　　特别是WebModel(ViewModel)的理解和描述很到位，避免了搞ViewModel的设计过渡之嫌。如果你有设计ViewModel的话.......
　　详细学习地址：http://www.cnblogs.com/KnightsWarrior/archive/2010/12/09/1900832.html
　　建议：把FrameWork给大伙开开源..........
　　 Artech：
　　

作者描述：我在《WCF全面解析》中的一个实例的解决方法结构，基本思路是：先模块（这里指粗粒度模块，可以看成子系统）（两个业务模块：Products、Orders，一个非业务模块：Infrastructure），后层次。 Products.BusinessEntity：提供的业务实体（Business Entity）类型的定义。一般来讲，业务实体和数据契约是不同的，在这里为了简单起见，我们不仅仅将二者合一，还将业务实体作为ASP.NET MVC的Model使用； Products.DataAccess：数据访问层，在这里单纯地提供对数据库的访问了。该项目具有针对Products.BusinessEntity的项目引用； Products.BusinessComponent：也可以称为业务逻辑层，真正的业务逻辑实现 在这里。该项目具有针对Products.BusinessEntity和Products.DataAccess的项目引用； Products.Service.Interface：WCF服务的契约接口定义在这里。该项目具有针对Products.BusinessEntity的项目引用； Products.Service：用于定义实现了上述契约接口的服务。该项目具有针对Products.Service.Interface 、Products.BusinessEntity和Products.BusinessComponent的项目引用； Products：为本模块提供基本的功能，不仅仅包含对服务的调用，也包括一些必要的逻辑处理。该项目具有针对Products.BusinessEntity、Products.Service.Interface和Products.Interface的项目引用； Products.Interface：模块提供给其他模块的服务接口。该项目具有针对Products.BusinessEntity的项目引用。

点评：Artech算是园子里的大佬，貌似还出了书，不过发的这个架子有点出乎我意料，存在有一些值得商榷的问题：
1.从架子中的命名和大体结构明显看出是走的DDD,在DDD中数据访问的具体实现(就是夹子里的DataAccess)应该是放在基础设施层（就是夹子里的Infrastructure），而Artech却貌似只把Infrastructure作为了"非功能性需求"的Framework去用。并把Infrastructure叫“非业务模块”，显得有些外行....
2.Products.BusinessComponent业务逻辑层 直接引用了Products.DataAccess，这也是个严重的问题，如果DataAccess是没有接口的，那么业务逻辑层依赖数据访问层，在DDD和马丁大叔的企业架构设计中，是一个反模式！！！，如果DataAccess里有接口，那么，DataAccess的接口应该是放在业务逻辑层的，然后通过依赖反转去用，而DataAccess的具体实现是放在Infrastructure里的。
3.如果没有用WCF，那么我认可可以省略掉DTO，但架子里上的WCF,还把DTO和PO合二为一，这个我非常不赞同。
4.Products层和Products.BusinessComponent层边界不清晰，按Artech描述 ，两个层里都可以放业务逻辑，但描述的模棱两块。而且基本可以看出Products.BusinessEntity又还是失血模型，这个设计完全让人摸不着头脑。Products层我猜是有点DDD中Application层的意思，但Artech明显做的不对。
总之我感觉这个架子，装的成分比较大，思路十分不清晰，命名很不规范，有失水准。　　
　　大伙也把自己的发在回复里，然后我统一在帖子里整理，共同学习进步
　　大伙也把自己的发在回复里，然后我统一在帖子里整理，共同学习进步
　　大伙也把自己的发在回复里，然后我统一在帖子里整理，共同学习进步