关于应用层次设计的讨论

哥， 我没说不分层啊。

基本的mvc还是需要的， 只是一个小网站弄一大堆Dao接口，Dao impl，Service接口，Service imple合适吗。 说得越多越扯得远，我感觉我的意思被曲解了，万事无绝对，我不会说“完全不分层”的。。。 不说了

姐去面试，跟面试官说姐用的是第二种设计，面试官立即跟姐翻脸，可见面试官是很不合格的，为什么面试姐的面试官都是这样的，有时去面试跟吵架一样，姐找不到工作。。。。

呵呵，吵架！是争论吧，我觉得敢于跟面试官争论技术问题的人应该不差。我面试别人，一般只问类似此贴的问题，能说个1、2、3来，并且有非常深入的体会，就差不多了。不会去问具体技术的问题，如果能对此类问题有个认真的思考的话，技术学起来应该差不到哪里去。另外一个是对工作的态度，当然这个不好把握，被面试者都说自己态度好，是不是这样还真收才知道。

这样的面试官，确实很不合格。

你只是不喜欢那么多的空类而已，可能你的业务逻辑太简单了吧，我们的项目很少有空的，当然我们是三流公司可能设计的比较挫，求指导。

分层的主要目的是解耦，也包括内聚（相关类聚合在一个包中/模块中）：

1、共性抽象是必要的，如CRUD。

2、如你开发个用完就扔的功能，则可以直接写具体类（控制器类、服务类、Dao类），无需定义接口，也没有必要定义接口，因为只有你再用，我认为是模块内聚的。

3、如果你需要对外提供服务，则应该定义且必须定义接口，接口就是契约，方便交流和测试，我认为这里主要为了解耦（服务消费者不需要知道服务是如何生产的）。

因此项目不管大小，抽象共性是必须，然后考虑高内聚（自己人使用），当需要为提供服务（许多人使用）时考虑低耦合。即项目大小不是绝对因素。

即实际项目开发可以这样：
1、自己人使用（模块内），全部使用具体类，不定义接口；
2、如果别人想用你（其他模块），你提供一个接口，只暴露需要的功能（窄接口）。

ls已经是双钻级别，这个成长速度值得各位学习的，呵呵

非常感谢，完全同意您的观点。
模块内内聚，模块间低耦合。

模块的划分，依据业务模型抽象。这样的设计，能够保证模块间依赖尽可能的小，一个模块内的变化尽量少的影响其他模块；一个模块能够单独的提供一类的服务，便于模块的独立，创造更大的伸缩空间。由于模块的规模相对系统来说，也比较小，因此一个模块的维护性更强，整个系统也更稳固。

不知我这样理解是否正确？

高内聚，低耦合是系统设计的灵魂，那么如何做到这点呢？
那就得有6大设计原则来保证了

如何做到高内聚，低耦合，我的理解是设计原则可以保持模块，而如何保持层于层之间的高内聚，低耦合，应该从更高的领域来看待，mvc就是一个很好的例子。

因为对某些个系统做了一些个假设，认为不需要暴露接口，而系统的生命期内，假设是否成立，没有人能够验证，也更加没有人能够保证！

在这种情况下，很多公司就开始使用第二种方式，当需要暴露接口的时候，代码需要大幅度的调整，并且可能导致层次间的耦合性提高！

所以，为什么mvc会得到很多人的赞誉，为什么很多人会自以为是的再mvc上做裁剪！

我想说，当你裁剪一种方式的时候，是否可以充分的验证下，裁剪的假设，更好的评估下项目的制约因素。