回忆被三层架构忽悠的日子，上当的同学自觉举手

       回忆第一次接触三层架构，看那些文章，好像走出了菜鸟的圈子，俺做的项目也是有架构的，还可以到处吹牛，俺的项目是基于***架构的，颇有那些做java的风采。

      在网上看到的三层架构大多数这个样子的，大家最常举得案例便是数据库工厂，我们的项目可能是mysql数据库，也可能是sqlserver数据库，还可能是未知的数据库，从那时起，我就知道了接口是什么东西，看了好多文章，也知道了什么叫基于接口的开发。

   而且三层架构果然是真的好像商标一样，出现在各种技术社区，尤其是那些源代码网站，当时为了学习，也从网上下了很多源代码进行观摩，学习，就连面试的时候，都要被问“你会三层构架吗”，当然，不管会不会，我都是会的，大家懂得。

 

也不知道是缺乏知识产权保护，还是缺钙缺铁，还是缺什么，我下载到的源码总是这个样子，开始我以为我是菜鸟，也就只能这个样子，毕业后进入高手如云的公司，肯定不是这个样子。

       记得去年在某公司上班，打开项目一看，就好像我已经来过了一样，项目的名称都和我的电脑里面的项目差不多，什么BLL什么的。当时我就感觉头晕目眩，接口！接口！太可怕了，后来我在公司最常干的一件事情就是打电话，电话的内容很简单，那个谁谁，你把那个什么文件嵌入一下，我要改一下。偶想起来了，还有一件事情也很常见，就是我每打一次补丁，都要发一次邮件，要把所有人问一遍，这个dll能不能作为补丁发出去。

      去年年末的时候，看到一本菜鸟进阶的书，网友们称呼为微软技术百科全书的《微软技术构架指南》我才知道，原来3层构架乃至n层构架更多的是从部署的角度来来考虑。

    我心一凉，心想，我改一个功能时，那么的痛苦，发一个补丁时，那么的痛苦，原来公司的三层架构是山寨的，因为那个dal也罢还是bll也罢不能个单独拿出来部署在一台机子上，那什么这个东西搞的我如此的痛苦，如此的受罪，写代码嘛，应该愉快一点。

   后来看了一些书，这个可能和公司的业务性质，项目性质有关，例如做cs的客户端，可能一年升级一次，半年打一次补丁，但cs的服务器端，可能每晚都要打补丁。做bs的就不用说了，你不打几个补丁上去，老板都会觉得你是废物，干了这么长时间，网站竟然每一个新功能，每一个变化

  现在大多数公司的架构可能是这样，一个公司，分几个产品，由产品经理带头，一个产品经理，可能带一个到三个项目小组，组成一个大的单位，每个月可能是这么渡过的，

 

         所以按照网上流传的三层架构的，工作必然是辛苦，上线必然是痛苦的，加班必然是难免，新功能和旧功能搅和在一起，BUG总是难免的，搞的我们上班很累。

        有时候回忆自己上周都做了什么，写了几行代码，有时候发现，一周干的事情并不多，

        不知道大家用过微软的membership没有，我现在更倾向于将一个业务模块或几个关系紧密的ui用到的一些功能，

向membership一样独立的封装，也许不能去建立一个项目，发布一个dll，但是在原来的项目下建立一个文件夹，来放这几个类还是可以的，虽然我现在不清楚用什么样的方式去架构，或组织文件，才能让每个业务模块向membership一样用起来方便，这样开发方便，打补丁方便，测试方便，升级打补丁方便，

     我现在比较喜欢向这个的方向去组织代码，有时觉得菜鸟用架构一词不太合适，还是用组织文件和代码比较合适，菜鸟一定要低调

      Product 是具体的业务模块，这里没有公共方法，也没有HttpContext，也没有sesscion、cookie、cache等行向扩展的模块，对与每一个小的业务单元，我就建立一个文件夹，

因为vs默认建立一个文件夹就是一个命名空间，必要时候可以独立发布dll，对与每一个业务模块我是用部分类来组织的

public partial class Table	Table.cs
partial class Table	TableDal.cs
partial class Table	TableMethod.cs
public class TableProvider:Table	TableProvider.cs

 

方法还可以按照三层架构时去组织代码，这个业务模块对外就是一个对象TableProvider，虽然不能向membership那么强大，但现在也只能想到这些。

web常用的sesscion、cookie、cache等，我喜欢用WebExtensions将其独立封装，因为这些模块都是可以扩展的，尤其是从单台服务器到分布式到集群，扩展也在这一块，业务模块我觉得变的比较少，所以吧他们独立拿出来。

 

上一遍 ：观察 HTML中id和name 的差异，被微软忽悠过的同学自动举手