三层架构，够不够 引言
反观如今的博客也好，技术文章也好，多是某一方面的技术细节,我个人不太喜欢这个方向,觉得意义不大。这些确实都是知识,我也十分尊重和感谢这些作者的贡献，因为我碰到问题也经常搜索这样的技术文章而得到了帮助。
可是，这与软件公司的实际工作总有个巨大的鸿沟，经常也看到很多人也类似的困惑，看了众多技术文章后，依然迷茫?更有人把这些困惑诉诸于文字。
商业软件注重的是技能,是所有技能的大整合，而不是技术点的罗列。把一个C#语言特性讲得再多再深,也只是MSDN帮助的一个翻版,也永远成不了商业软件。相反,讲解技术的代码示例,几乎都是商业软件的反面教材。
伟大的作家都是阅读了大量作品，从中汲取营养，才逐步成长，最后成为大家。可是，讽刺的是， 同是作为思维作品的软件设计，却较少有这种机会，各个公司都是互相封闭，甚至极其仇视代码分享的想法，美其名，版权。而开源的兴起，可以说，这个是最大的益处。只是，大多数开源者，本身都没有意识到。所以，发布是，仍然过于注重，软件的功能，而不是设计。
这里，不得不提一下源代码管理软件Git，与SVN和TFS相比，Git最大的特点就是就是业务域模型设计非常精彩，后两个都是基于文件的版本控制，而Git是基于整个代码树的版本控制。什么是DDD看看Git的业务模型，会有不同感想。诚然，Git的终端功能和用户使用上还有所欠缺，那只是时间的问题。相比之下，TFS和SVN虽然提供的最终功能很好，但由于底层设计的缺陷，这些功能如补丁一样，没能和业务模型融合到一起，终究会支离破碎。我很看好Git的将来。
目前,我正在组建团队,开发实际项目。并逐渐提炼完成了自己的一套框架。在这个过程中,融合消化整合了大量的技能。
现在,我想做的是个反向工程,解构这套框架,把设计思想,整合过程又一步步拆散,呈现给受众。这也是我之后技术作文的方向。这样的方式内容，不知诸位是赞同，反对还是无所谓？
这里是技能的整合几个例子:
- 三层架构的需要解构依赖关系（表现层依赖于业务层，业务层依赖于数据层），才能发挥更好的作用。如：用Repository隔离业务层和数据层，Repository的接口定义属于业务层层，而实现却属于数据层；用DTO（ASP.Net MVC称为View Model）来隔离表现层和业务层。然而，增加的复杂度又如何解决呢？
- 为了实现测试驱动(TDD),需要利用依赖注入(DI)来隔离类与类之间的直接联系,还要用AutoMock来提高写测试代码的效率,最后,进一步用用户故事的语法来组织测试代码,提高代码的可读性。遗留的问题是具体代码如何,有哪些已有工具可利用（nUnit, Machine Specification, Ninject, Resharper等等） ?
- 业务域驱动(DDD)与ORM工具Fluent nHibernate的一起使用,大大提高效率,注意是Fluent,几乎可纵做到零SQL, 零数据库表定义。 最终要的是，要用Repository隔离Domain和数据层，Repository的接口定义属于Domain层，而实现却属于数据层。
可以,看到,各种概念的交互,融合,最终是有机的成为一个整体框架。
从优秀到卓越TAG:架构 Asp Net
