.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:
我先来抛砖引玉:
传说中的弦哥:
tips:
1."解决方案文件夹"能帮助你很好的规划项目结构
2.通过对"解决方案文件夹"前面加数字1,2,3,4....,能让项目按你想要的顺序排序
3.公司名.项目名.包名.架构名的命名空间 命名约定能让你的项目结构更清晰
4.分项目的多少还是要根据项目具体情况和架构设计,分太多编译速度慢不说,其实用起来也麻烦
一晴 :
点评:一个比较简单的博客网站,用的是MVC,命名啥的还是比较规范的。
建议:可以把Controller和Model从网站项目中提出来
点评:典型的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给大伙开开源..........
大伙也把自己的发在回复里,然后我统一在帖子里整理,共同学习进步
大伙也把自己的发在回复里,然后我统一在帖子里整理,共同学习进步
大伙也把自己的发在回复里,然后我统一在帖子里整理,共同学习进步
posted on 2012-06-18 09:25 传说中的弦哥 阅读(16591) 评论(171) 编辑 收藏
评论
#123楼
佩服弦哥,和弦哥一个行业,不过相差甚远,以超越弦哥为目标...
话说《Asp.net大型项目实践系列 第二季》啥时更新?
#124楼
引用 @道法自然引用@Artech引用@传说中的弦哥引用@[秦时明月]@圣殿骑士@Artech恭喜三位中奖啊.......谢谢给我这个奖:)1. 我的这个结构主要考虑的是模块化,而不是层次化。或者在模块的基础上划分层次。2. 模块是以功能为主,模块封装业务功能和非业务功能。我主张在模块级别对外提供服务,而不是层次上对外提供服务。3、层次是模块为了实现自身功能而进行的层次划分,所以没有必要为每一个层次定义接口。DataAccess提供接口的一个很大的目的在于隔离数据存储,是对多种数据存储方式的支持。实际上很多类似与DbHelper就能够提供这样的功能。所以我很不喜欢为DataAccess定义接口,虽然...
这个点评碉堡了,藏经阁外一老僧,高啊!
#127楼
-----------------------------------------------------------
这个我觉得很合理,Provider的类型有很多种,不同类型的provider也有很多种的实现。
#128楼
引用 想提醒一下大家的是,物理分层和逻辑分层是有区别的,分层也和 .NET 的 project 拆分没有必然的联系。如果不会把很多东西拆开部署到不同的机器上,很多时候没有必要搞这么多花架子,拆这么多 DLL. 业务功能实现的很干瘪,却搞出几十个 projects 来唬人。引用来引用去的,管理 DLL 之间依赖关系的成本高了,稍不注意就会发生循环引用,然后解决的办法就是反射,IoC 啥的,累得很,性能又低,真的有必要吗?很多相对简单的系统,其实可以把不少 projects 合并到一个里面,按照 namespace 和文件夹拆分就可以了。
很认同,你一个名为IXXX的项目,就放一个接口,很多时候没必要这样做,完全可以和类似的项目合并。分层和分项目并不是一码事,甚至在一个项目里也能分层。
当然分层是如何分项目的参考因素之一,但我们也要参考一下文件的组织,部署的便利性,用户的可选性部署等等其他因素。
#130楼
@江大鱼
引用 @木野狐(Neil Chen)
引用引用想提醒一下大家的是,物理分层和逻辑分层是有区别的,分层也和 .NET 的 project 拆分没有必然的联系。如果不会把很多东西拆开部署到不同的机器上,很多时候没有必要搞这么多花架子,拆这么多 DLL. 业务功能实现的很干瘪,却搞出几十个 projects 来唬人。引用来引用去的,管理 DLL 之间依赖关系的成本高了,稍不注意就会发生循环引用,然后解决的办法就是反射,IoC 啥的,累得很,性能又低,真的有必要吗?很多相对简单的系统,其实可以把不少 projects 合并到一个里面,按照 namespace 和文件夹拆分就可以了。...
项目规模大的话,还是有必要的。小规模的话,这样做的确有点麻烦。
#132楼
#133楼[楼主]
#137楼
4、接口是是契约,是“服务”的接口,只有在对外提供服务的情况下需要定义接口。而一个模块为另一个模块提供服务,才需要定义接口。
----------------------------
蒋老师的这个观点,我很支持的。
PDF.NET框架通过3种方式来隔离具体的数据访问:
1,采用抽象的数据访问类;
2,采用XML化的SQL配置管理“SQL-MAP”技术;
3,采用抽象的SQL查询技术“OQL”,一种对象化的实体操作语言。
#138楼[楼主]
引用 DataAccess提供接口的一个很大的目的在于隔离数据存储,是对多种数据存储方式的支持。实际上很多类似与DbHelper就能够提供这样的功能。所以我很不喜欢为DataAccess定义接口,虽然PetShop是这样做的,很多项目也是这样做的,我依然觉得很丑。
4、接口是是契约,是“服务”的接口,只有在对外提供服务的情况下需要定义接口。而一个模块为另一个模块提供服务,才需要定义接口。
----------------------------
蒋老师的这个观点,我很支持的。
PDF.NET框架通过3种方式来隔离具体的数据访问:
1,采用抽象的数据访问类;
2,采用XML化的SQL配置管理“SQL...
你这是来打广告的 哈哈
#139楼
#148楼[楼主]
#153楼
1,分项目和分层没任何关系,上面这些例子里面很多都是同层不同模块封装在不同项目里而已。并没有本质上冲击实际上已经足够的五层左右的架构。
2,我理解的架构设计,是只有原则,没有固定形态的。就像水一样,因容器不同而改变其形态。项目架构设计,因需求不同而改变形态,不变的只是少量的例如解耦合,封装变化点,便于测试,提高代码重用性之类的“奥义”。所以也就不存在样板框架这种东西。
3,在满足最基本的一个优质架构基础之后,我追求的从来都是尽量少写代码,尽量简化结构,能不要就不要,能不写就不写,能不做就不做。渴望的是一种“正好够用”的境界。当然,我一直到不了这种境界,所以很多时候我的实践就变成了“千万别多”。
4,为了满足“正好够用”,同时又能够在需求改变时正确应对,不导致代码腐败,最重要的其实就是最先的需求分析,预先提取出“刚刚够”的变化点。其次就是永不停止的重构。大部分时间下,重构的代价并不高,并且充满乐趣。
5,平生看见过度设计的东西就会皱眉头,始终记得两句名言:一切计算机问题都可以通过引入多个非直接层的方式解决。除了引入了过多非直接层造成的过度复杂问题。
#156楼
引用 说说我的意见吧:
1,分项目和分层没任何关系,上面这些例子里面很多都是同层不同模块封装在不同项目里而已。并没有本质上冲击实际上已经足够的五层左右的架构。
2,我理解的架构设计,是只有原则,没有固定形态的。就像水一样,因容器不同而改变其形态。项目架构设计,因需求不同而改变形态,不变的只是少量的例如解耦合,封装变化点,便于测试,提高代码重用性之类的“奥义”。所以也就不存在样板框架这种东西。
3,在满足最基本的一个优质架构基础之后,我追求的从来都是尽量少写代码,尽量简化结构,能不要就不要,能不写就不写,能不做就不做。渴望的是一种“正好够用”的境界。当然,我一直到不了这种境界,所以很多时候我的实践就变...
非常同意,顶
#162楼
只限西安地区,主要交流html、css、js、ajax、jQuery、Asp.Net、Linq、MVC、SQL、IIS等web开发相关技术,欢迎大家加群,非技术人员请勿进群,谢谢合作!!!
#170楼
引用 @传说中的弦哥
就你那点道行还点评。你就吹吧。有本事把你的架子放出来给人家看看。别在园子里装牛人。低调乃是美得。装牛只会引来一些无为的争端,何必呢?
看不出一点装X。
有可能你不太接受他的风格