“三层架构，够不够”

原文: “三层架构，够不够” 引言 ----- 我技术作文的方向

反观如今的博客也好，技术文章也好，多是某一方面的技术细节,我个人不太喜欢这个方向,觉得意义不大。这些确实都是知识,我也十分尊重和感谢这些作者的贡献，因为我碰到问题也经常搜索这样的技术文章而得到了帮助。

可是，这与软件公司的实际工作总有个巨大的鸿沟，经常也看到很多人也类似的困惑，看了众多技术文章后，依然迷茫?更有人把这些困惑诉诸于文字。

商业软件注重的是技能,是所有技能的大整合，而不是技术点的罗列。把一个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就是为了团队之间合作更方便 代码写的更规范

硬来个三 那就是 数据访问和 窗体功能代码连接不那么紧密
------解决方案--------------------