|
锁定老帖子 主题：关于应用层次设计的讨论
精华帖 (0) :: 良好帖 (4) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-04-12
发现的框架多的不行，程序员都热衷学习各种框架的使用而忽视如何吸收优秀框架的思想，讨论面向对象的帖子越来越少。
|
| 返回顶楼 | |
|
发表时间：2012-04-12
mqlfly2008 写道 KimHo 写道 ericchi 写道 jinnianshilongnian 写道 分层的主要目的是解耦，也包括内聚（相关类聚合在一个包中/模块中）：
1、共性抽象是必要的，如CRUD。 2、如你开发个用完就扔的功能，则可以直接写具体类（控制器类、服务类、Dao类），无需定义接口，也没有必要定义接口，因为只有你再用，我认为是模块内聚的。 3、如果你需要对外提供服务，则应该定义且必须定义接口，接口就是契约，方便交流和测试，我认为这里主要为了解耦（服务消费者不需要知道服务是如何生产的）。 因此项目不管大小，抽象共性是必须，然后考虑高内聚（自己人使用），当需要为提供服务（许多人使用）时考虑低耦合。即项目大小不是绝对因素。 即实际项目开发可以这样： 1、自己人使用（模块内），全部使用具体类，不定义接口； 2、如果别人想用你（其他模块），你提供一个接口，只暴露需要的功能（窄接口）。 非常感谢，完全同意您的观点。 模块内内聚，模块间低耦合。 模块的划分，依据业务模型抽象。这样的设计，能够保证模块间依赖尽可能的小，一个模块内的变化尽量少的影响其他模块；一个模块能够单独的提供一类的服务，便于模块的独立，创造更大的伸缩空间。由于模块的规模相对系统来说，也比较小，因此一个模块的维护性更强，整个系统也更稳固。 不知我这样理解是否正确？ 高内聚，低耦合是系统设计的灵魂，那么如何做到这点呢？ 那就得有6大设计原则来保证了 如何做到高内聚，低耦合，我的理解是设计原则可以保持模块，而如何保持层于层之间的高内聚，低耦合，应该从更高的领域来看待，mvc就是一个很好的例子。 因为对某些个系统做了一些个假设，认为不需要暴露接口，而系统的生命期内，假设是否成立，没有人能够验证，也更加没有人能够保证！ 在这种情况下，很多公司就开始使用第二种方式，当需要暴露接口的时候，代码需要大幅度的调整，并且可能导致层次间的耦合性提高！ 所以，为什么mvc会得到很多人的赞誉，为什么很多人会自以为是的再mvc上做裁剪！ 我想说，当你裁剪一种方式的时候，是否可以充分的验证下，裁剪的假设，更好的评估下项目的制约因素。 哈哈，说到了目前部分公司的症结了。 “因为对某些个系统做了一些个假设，认为不需要暴露接口，而系统的生命期内，假设是否成立，没有人能够验证，也更加没有人能够保证！“。非常经典到位的点评。 所以，没有验证下，就随意的裁剪。 |
| 返回顶楼 | |
|
发表时间：2012-04-12
mqlfly2008 写道 在这种情况下，很多公司就开始使用第二种方式，当需要暴露接口的时候，代码需要大幅度的调整，并且可能导致层次间的耦合性提高！ 对于这种情况（因为如我们企业开发 有很多模块都是独立的），万一有第三方需要，可以单独制定 窄接口（单独设计一套用户接口暴露），保持模块内部的内聚 对于从初期看外部就需要调用的，可以在初期设计成接口 SpringMVC很好的遵循开闭原则（对功能点的扩展是开放的，但对流程的修改是绝对不可以的），而且提供大量默认实现！ 1、如SpringMVC的HandlerMapping 第三方需要这个东西，因此初期设计成接口是必然的； 2、如MappedInterceptor等直接”public final class MappedInterceptor“ 因为内部使用，不允许你扩展。 没有完美，简单有效即可。 |
| 返回顶楼 | |
|
发表时间：2012-04-12
ericchi 写道 mqlfly2008 写道 KimHo 写道 ericchi 写道 jinnianshilongnian 写道 分层的主要目的是解耦，也包括内聚（相关类聚合在一个包中/模块中）：
1、共性抽象是必要的，如CRUD。 2、如你开发个用完就扔的功能，则可以直接写具体类（控制器类、服务类、Dao类），无需定义接口，也没有必要定义接口，因为只有你再用，我认为是模块内聚的。 3、如果你需要对外提供服务，则应该定义且必须定义接口，接口就是契约，方便交流和测试，我认为这里主要为了解耦（服务消费者不需要知道服务是如何生产的）。 因此项目不管大小，抽象共性是必须，然后考虑高内聚（自己人使用），当需要为提供服务（许多人使用）时考虑低耦合。即项目大小不是绝对因素。 即实际项目开发可以这样： 1、自己人使用（模块内），全部使用具体类，不定义接口； 2、如果别人想用你（其他模块），你提供一个接口，只暴露需要的功能（窄接口）。 非常感谢，完全同意您的观点。 模块内内聚，模块间低耦合。 模块的划分，依据业务模型抽象。这样的设计，能够保证模块间依赖尽可能的小，一个模块内的变化尽量少的影响其他模块；一个模块能够单独的提供一类的服务，便于模块的独立，创造更大的伸缩空间。由于模块的规模相对系统来说，也比较小，因此一个模块的维护性更强，整个系统也更稳固。 不知我这样理解是否正确？ 高内聚，低耦合是系统设计的灵魂，那么如何做到这点呢？ 那就得有6大设计原则来保证了 如何做到高内聚，低耦合，我的理解是设计原则可以保持模块，而如何保持层于层之间的高内聚，低耦合，应该从更高的领域来看待，mvc就是一个很好的例子。 因为对某些个系统做了一些个假设，认为不需要暴露接口，而系统的生命期内，假设是否成立，没有人能够验证，也更加没有人能够保证！ 在这种情况下，很多公司就开始使用第二种方式，当需要暴露接口的时候，代码需要大幅度的调整，并且可能导致层次间的耦合性提高！ 所以，为什么mvc会得到很多人的赞誉，为什么很多人会自以为是的再mvc上做裁剪！ 我想说，当你裁剪一种方式的时候，是否可以充分的验证下，裁剪的假设，更好的评估下项目的制约因素。 哈哈，说到了目前部分公司的症结了。 “因为对某些个系统做了一些个假设，认为不需要暴露接口，而系统的生命期内，假设是否成立，没有人能够验证，也更加没有人能够保证！“。非常经典到位的点评。 所以，没有验证下，就随意的裁剪。 这种情况可以通过定义 用户接口解决 |
| 返回顶楼 | |
|
发表时间：2012-04-12
jinnianshilongnian 写道 ericchi 写道 mqlfly2008 写道 KimHo 写道 ericchi 写道 jinnianshilongnian 写道 分层的主要目的是解耦，也包括内聚（相关类聚合在一个包中/模块中）：
1、共性抽象是必要的，如CRUD。 2、如你开发个用完就扔的功能，则可以直接写具体类（控制器类、服务类、Dao类），无需定义接口，也没有必要定义接口，因为只有你再用，我认为是模块内聚的。 3、如果你需要对外提供服务，则应该定义且必须定义接口，接口就是契约，方便交流和测试，我认为这里主要为了解耦（服务消费者不需要知道服务是如何生产的）。 因此项目不管大小，抽象共性是必须，然后考虑高内聚（自己人使用），当需要为提供服务（许多人使用）时考虑低耦合。即项目大小不是绝对因素。 即实际项目开发可以这样： 1、自己人使用（模块内），全部使用具体类，不定义接口； 2、如果别人想用你（其他模块），你提供一个接口，只暴露需要的功能（窄接口）。 非常感谢，完全同意您的观点。 模块内内聚，模块间低耦合。 模块的划分，依据业务模型抽象。这样的设计，能够保证模块间依赖尽可能的小，一个模块内的变化尽量少的影响其他模块；一个模块能够单独的提供一类的服务，便于模块的独立，创造更大的伸缩空间。由于模块的规模相对系统来说，也比较小，因此一个模块的维护性更强，整个系统也更稳固。 不知我这样理解是否正确？ 高内聚，低耦合是系统设计的灵魂，那么如何做到这点呢？ 那就得有6大设计原则来保证了 如何做到高内聚，低耦合，我的理解是设计原则可以保持模块，而如何保持层于层之间的高内聚，低耦合，应该从更高的领域来看待，mvc就是一个很好的例子。 因为对某些个系统做了一些个假设，认为不需要暴露接口，而系统的生命期内，假设是否成立，没有人能够验证，也更加没有人能够保证！ 在这种情况下，很多公司就开始使用第二种方式，当需要暴露接口的时候，代码需要大幅度的调整，并且可能导致层次间的耦合性提高！ 所以，为什么mvc会得到很多人的赞誉，为什么很多人会自以为是的再mvc上做裁剪！ 我想说，当你裁剪一种方式的时候，是否可以充分的验证下，裁剪的假设，更好的评估下项目的制约因素。 哈哈，说到了目前部分公司的症结了。 “因为对某些个系统做了一些个假设，认为不需要暴露接口，而系统的生命期内，假设是否成立，没有人能够验证，也更加没有人能够保证！“。非常经典到位的点评。 所以，没有验证下，就随意的裁剪。 这种情况可以通过定义 用户接口解决 对于接口的发现，个人观点是，可以适当的冗余设计，而且越早发现项目的结合部，对项目越来越有利，这是我认为可以冗余设计的观点的本源。 后期通过用户接口，重新在原有系统上架构一层分发（个人认为） 会直接导致新用户需求对接口的调整需求和原系统的需求调整，而这俩个需求很有可能调的都是原系统的某一部分的方法，或者是多个窄接口。 一个方法担负着多个需求源的方式，真的让人很担心该方法的承受能力！这应该也会提高对原系统的整体架构和代码管理的要求。 当然也可能是我对用户接口了解的不够，呵呵。。。欢迎指导 |
| 返回顶楼 | |
|
发表时间：2012-04-12
最后修改：2012-04-12
”这种情况可以通过定义 用户接口解决“
恩，定义接口可以解决。但正如上所说，有些人会做裁剪。 譬如，我提出的问题。 有人设计的时候，会把每个DAO接口省略。取而代之的，是在AbstractBaseManager中抽象一个共用的BaseDao实现。 这样就存在一个问题，要不要抽象。我抽象了，就意味着所有继承这个抽象类的都有这个共性。而这个是不是共性，存不存在潜在的变化，都没有验证。对于某些简单模块可能比较确定，但对于整个系统都这样应用，就有些牵强了。 所以，我认为有些接口是必须要定义或提供的。 |
| 返回顶楼 | |
|
发表时间：2012-04-12
ericchi 写道 所以，我认为有些接口是必须要定义或提供的。 这个是肯定的 |
| 返回顶楼 | |
|
发表时间：2012-04-12
最后修改：2012-04-12
view
vo action logic service po dao 以模块划分 |
| 返回顶楼 | |
|
发表时间：2012-04-13
结构2的意思是只使用一个BaseDao吗？ sql或者hql都定义在xml中？还是都在业务逻辑里面？ 之前项目一般都是一个实体的操作对一个DAO，当然也会抽象出BaseDao
|
| 返回顶楼 | |
|
发表时间：2012-04-13
crud0906 写道 结构2的意思是只使用一个BaseDao吗？ sql或者hql都定义在xml中？还是都在业务逻辑里面？ 之前项目一般都是一个实体的操作对一个DAO，当然也会抽象出BaseDao
恩，结构2的意思就是整个系统只使用一个baseDao。sql没有定义在xml，而是绑定到了业务逻辑层里，确切的说是每个Service中。 |
| 返回顶楼 | |
