关于应用层次设计的讨论

呵呵，一个项目或者产品，是要根据领域划分成多个模型的。每一个领域只对外提供该领域的服务，至于内部实现别的领域是不知道的。

每一个领域可以单独的成为一个project，独立开发。这样按照一定的粒度划分后，能够保证一个project不会出现成百上千的Dao，Service。而每一个project内部，还是要分层的。如果不分层，会有多混乱？难以想象。

我并不是说不能分层、编程的人总是要靠理性来思考、逻辑来分析的。我不会说那么绝对的话。

我感觉到的是许多情况下分层过多而已，你怎么偷换概念为“不分层”呢？ 并且我说的分层过多并不是说“全部”分层过多，我参与的项目中都见过这种情况，惭愧的是，我自己也那么做了。我自己动手为每个Dao接口、Dao实现类、Service接口、Service实现类敲好放哪，但是之后基本大部分都没用到。现在想起就可笑，感觉自己完全是因为重复的技术而变得如机器人一样。

如果一个大型项目，结构复杂，参与人员众多，那么我也很赞同结构分层清晰，开发维护都方便。但是有多少情况属于大型项目呢？ 大炮轰炮台非常合理也奏效，如果大炮轰苍蝇。。。

分层是必须的，分层思想促进科技的发展，就拿计算机来说吧，有硬件层、操作系统、再到应用，如果没有分层或者没有合理分层，那么我们现在如果实现小小的应用功能，不知道要倒腾到什么时候。

所以多数时候可能是理解分层的开发人员没有理解透

 

这就是大小之分啊，即便是微机，上面有各种硬件CPU、内存等等，必须要分层一层层封装。

但是一个手表、一个电梯上面添加这些分层就不合理了吧。

万事无绝对，编程不是为了编程，而是为了更好的实现需求功能。代码量、工作效率都需要考虑的。怎么能说“分层是必须的”呢？我感觉不够客观，太唯心了。如果让我现在回头做我以前做过的项目，我肯定会将那些小项目中的分层砍掉一些。

说的很有道理

谁说一个手表、一个电梯就不分层了，只是分层的范围大小、可见性、个人的理解不同而已。比如电梯也有控制系统，这个也是属于一层；再比如手表的外壳也属于一层，每个齿轮大小规定也属于分层思想的应用。

大项目用第一种，小项目第二种

分层数量。。。 分层细化程度。。。

我从来没说完全抛弃分层，只是不喜欢过度的分层和不合时宜的分层。

哎， 纠结。 我的核心思想就是Java里面开发Web应用用到的分层开发大型系统很好，但是其他许多时候就属于过度封装和分层。比如一个小企业网站你搞各种dao接口、dao实现、service接口、service实现、model等等。 一整套下来得几百个类，其中大部分还是空壳。有什么用啊？

恩，过度设计和设计不足的争论。。呵呵

小企业网站也要分层吧，apache的博客系统 Roller 功能不多，应该属于中小吧，但人家还是不是照样分层。我正在应用Roller做二次开发，效果很好。

建议有时间研究一下开源软件，相对其他开源系统，这个Roller属于比较容易上手的。看看我们在开发中写的代码和人家有什么不一样。