咱们在讨论的时候能不能先确定一个明确的范围呢？最好能把自己的经历简单说一下。

 

      昨天晚上看到了三层,又见三层。别了，三层 有点想法，在这里说一下。和周六活动的讨论没有什么关系，特此声明！

      讨论是好的，但是范围不明确的话，就很容易跑题，也容易带出来火药味儿。想这两天又热起来的三层，其实涉及的范围是很广的，一层、一层半、两层、三层、n层、贫血、冲血、OO、储存过程、分布式、MVC，个人经历、项目特点，复杂程度，成员水平，项目经验，行业特点的了解程度等等。我们在讨论三层的时候，会自觉不自觉的联想到上面的一点或者几点。

 

      另外就是每个人的经历是不同的，每个人的项目的特点也是不一样的，同样的方法适合你的项目，但是不一定适合我的项目。而我们在讨论的时候这些都是很模糊的，都在潜意识里面认为是在依据自己的项目的情景来讨论。这就产生了矛盾呀，每个人的项目特点都是不一样的呀。

      再有一个就是，我们视乎都喜欢现提出来“反对意见”。看到了别人提到了一种方法，只要是自己不熟悉的，就会不自觉的找他的缺点，找他的不适合的地方。包括我在内，总是想这么做。不知道是什么原因。

      其实我们都知道银弹是不存在的，那么为什么我们要用银弹的标准去衡量一种方法（一个架构、一个解决方案）呢？比如说三层，他不是银弹，不是万能的，那么他就有其适用范围呀，但是谈论（或者说明）其使用范围的好像不多见。

      最后就是一刀切。在一个项目里面如果采用了一种方法，那么不管是什么情况（需求），统统第都要用这种方法来解决，不管适合不适合，美其名曰：统一风格。我们是不是需要变通一下子呢，简单的业务需求我们就用“简单”的方式来解决，复杂的业务逻辑我们就用“复杂”的方式来解决。比如我们用了三层了，用了实体类的，就不管三七二十一，都来个实体类。

 

ps：不知道我这么说是不是会更乱了，呵呵。