“三层架构，够不够”
原文: “三层架构，够不够” 引言 ----- 我技术作文的方向
反观如今的博客也好，技术文章也好，多是某一方面的技术细节,我个人不太喜欢这个方向,觉得意义不大。这些确实都是知识,我也十分尊重和感谢这些作者的贡献，因为我碰到问题也经常搜索这样的技术文章而得到了帮助。
可是，这与软件公司的实际工作总有个巨大的鸿沟，经常也看到很多人也类似的困惑，看了众多技术文章后，依然迷茫?更有人把这些困惑诉诸于文字。
商业软件注重的是技能,是所有技能的大整合，而不是技术点的罗列。把一个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, 零数据库表定义。
可以看到,各种概念的交互,融合,最终有机的成为一个整体。
[解决办法]
看不懂你在说什么。
一会儿是git，一会儿是di，一会儿是tdd。你是提问呢？还是分享技术呢，还是评论什么呢？总之没看懂你想说什么。而且你说了半天也和没说什么一样。
[解决办法]
应注重软件的设计，这么一个角度说的。
貌似应该是Business App的Enterprise Architecture范畴。
[解决办法]
lz啊，你自己没知识就请好好学习学习再来发言。
GIT比TFS哪牛啦？简直不知所畏
[解决办法]
git比svn晚了一代，说到底，git是开发流程去中心化、敏捷开发流行起来的产物。因此，与其说看好git，不如说git代表的开发方法会越来越流行。
作为source control，git确实有比tfs过人之处，但是tfs并非单一的版本控制，因此两者也没有什么可比性。
[解决办法]
反观如今的博客也好，技术文章也好，多是某一方面的技术细节,我个人不太喜欢这个方向,觉得意义不大。这些确实都是知识,我也十分尊重和感谢这些作者的贡献，因为我碰到问题也经常搜索这样的技术文章而得到了帮助。
可是，这与软件公司的实际工作总有个巨大的鸿沟，经常也看到很多人也类似的困惑，看了众多技术文章后，依然迷茫?更有人把这些困惑诉诸于文字。
商业软件注重的是技能,是所有技能的大整合，而不是技术点的罗列。
你不觉得你自己说的话很矛盾么~？
商业软件 大包含 技能 技能 包含 技术点
等于 商业软件 包含很多技术点
然后你说你不喜欢技术点的细节~
对于一个公司来说更关注软件是否能产生经济价值
但对于我们程序员来说要把软件做得更好。
当然我们也希望软件能更好产生经济价值。
但分工合作，这些就拜托业务人员把。
没有SQL直接对数据表操作，便于重构。 便于业务模型与数据模型的独立性。
业务员也不会因为我写了SQL就给我加钱。
有些功能ORM工具要完成会比sql复杂很多，而且更加浪费内存
[解决办法]
我写东西的时候常常有词贫的感觉
不知道你有没有过
其他,还有些类似的问题/选择:
代码可读性 vs 代码效率
领域驱动 vs 非领域驱动
我都选择前者.(是要选择合适)
代码可读性 vs 代码效率
（我以前的老总跟我们说过，当年他在硬件上写程序，只有几k的空间可以用）
他说首先考虑的是能不能写小 算法能不能精简，
代码在可读，效率再高 没有足够的空间运行 那都是浮云
（举例子有点偏激 所以看下面的）
考虑东西不是非得要这样这样才是对的。
对面对象很好 但面向过程也可以用（小项目或者一些小工具可以用）
领域驱动很好 非领域驱动（小项目或者一些小工具可以用（比如邮件群发...））
套用《Head First设计模式》上的一句话
但你写个Hello World程序的时候都用设计模式去写
那就说明你有病了
[解决办法]
有那么复杂吗 感觉三层下来就是 俩好处
1就是 为了思路清晰 写大项目一样能上手
2就是为了团队之间合作更方便 代码写的更规范
硬来个三 那就是 数据访问和 窗体功能代码连接不那么紧密
[解决办法]
有那么复杂吗 感觉三层下来就是 俩好处
1就是 为了思路清晰 写大项目一样能上手
2就是为了团队之间合作更方便 代码写的更规范
硬来个三 那就是 数据访问和 窗体功能代码连接不那么紧密
[解决办法]
首先，程序是给机器运行的，不是给人看的，将不同功能的代码段隔离开是有好处，但是过份强调设计模式，像 Java 那样，满篇接口抽象，运行效率低下，占用资源巨大，代码修改繁琐，这样的垃圾程序要它有何用
[解决办法]
[解决办法]
[解决办法]
[解决办法]
[解决办法]
什么玩意。。。。乱七八糟的。
很多软件用汇编写的不一样很好的再维护吗？
[解决办法]
你觉得 Java 那样满篇的接口抽象类可读性高吗？
[解决办法]
汗。。。 任何话都有背景条件 其实楼主说的 还是挺有道理的啊。。。
[解决办法]
三层确实是个好东西 用下来会觉得很舒服 不晓得你说的这么多是神马意思 三层攻不够？ 其实啊 够 ！！遇见问题了解决下 还是挺好的呢！
[解决办法]
看不懂，你是准备比较git和tis还是说三层架构呢？