User Interface即UI层该层作为数据输入和展示的界面是与用户交互的有效途径所以它起着至关重要的作用。往往给人第一印象的就是UI层在设计的时候也要根据不同的技术或者不同的要求进行斟酌。通常可以把UI分为B/S UI、C/S UI以及WEB服务。在这里就是我们的ASP.NET项目。02WebModelCommon这层作为UI与领域逻辑的中间层它的充当了桥梁、筛选、过滤和验证的作用。它主要包括两个工程WebHelper主要提供给UI一些常用操作。WebLogic主要对UI与领域逻辑的数据进行转换、筛选、验证及过滤操作。03Business LogicDomain Model Data Model Layer始终是应用程序的核心必须投入大量精力按照面向对象的分析和设计 (OOAD) 最佳做法进行设计同时按照OOP进行开发。04FrameWork主要包括数据访问框架、通用权限框架、异常和日志处理框架、IOC框架、AOP框架等基础或常用功能。05SOA这一层不是必须的根据项目的具体情况进行取舍如果业务比较复杂且交互项目繁多那么SOA可以减轻我们的负担如果业务比较单一且相对简单就可以直接调用或者使用Web Service/Remoting/WCF作为通信框架即可。在实施SOA的过程中可以自己使用WCFWF搭建一个小型轻量级的SOA框架也可以使用诸如Biztalk等软件。06Reference这里主要包括第三方的框架和组件项目把这些文件分门别类地集中放在此目录下。07Solution Items项目的规范、流程、重要文件等。08Test这里主要放置测试需要的一些信息如测试版本、测试文档等。09Publish这个文件夹主要放置发布的版本。作者的获奖感言比较关心有没有奖品 其实这个架构比较复杂一点考虑到经常扩展和升级如果小项目就没有必要这么折腾了。当时是支持多国家、多设备比如同样的项目可以在新加坡和美国根据IP的不同来自动寻址访问同时根据设备的不同而又有两套路径手机用户导航到手机网站页面PC用户就到正常页面。关于数据访问层有一个适配器可以通过配置选择ORM自己写的一套类库封装在Framework里面还是经典方式SQL和存储过程等全部单独写在XML文件里面通过读取XML文件进行调用这样维护和版本升级比较方便同时为了降低系统的负载同时提高用户的响应能力我们采用了MSMQ和SSB来组织消息队列。另外数据层都有Mock data for testing这样就能保证项目扩展和升级造成的相互依赖而耗费过多的时间和精力。如果有时间可以写一篇文章出来大家探讨回复感言奖品是必须的针对此架构写一篇详细的文章并附上源码。小项目确实没必要搞这么复杂可以参考帖子里的“土鳖实战派”那个分层我觉得就挺实在的。Mock data for testing是个好办法有空介绍些好的Mock框架。最佳吐槽奖 [秦时明月] 他只在评论里淡淡的回复了一句“其实我只想说一点:大家都乱了.”。轻轻的来不留一片架子。不过弦哥是不会放过他的......于是乎弦哥到他的博客异地远程联网技术 - 博客园里搜刮了一番发现了他其实也有架子“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.InterfaceWCF服务的契约接口定义在这里。该项目具有针对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还费劲呢也是看了你的帖子才豁然开朗。我先来抛砖引玉传说中的弦哥:tips1.解决方案文件夹能帮助你很好的规划项目结构2.通过对解决方案文件夹前面加数字1,2,3,4....能让项目按你想要的顺序排序3.公司名.项目名.包名.架构名的命名空间 命名约定能让你的项目结构更清晰4.分项目的多少还是要根据项目具体情况和架构设计,分太多编译速度慢不说,其实用起来也麻烦一晴 点评:一个比较简单的博客网站用的是MVC命名啥的还是比较规范的。建议可以把Controller和Model从网站项目中提出来xu_happy_you 点评典型的Petshop控BLLDALMODEL网站 的三层架构通过工厂模式来调用DAL建议可以进一步尝试DDD并用DI依赖注入代替工厂模式微软根据DDD架构做的一个分层示范项目,NLayerAppV2下载网址http://microsoftnlayerapp.codeplex.com/workitem/6687微软的一个CRM项目下载网址http://orchard.codeplex.com/
