|
这个主题共有 9 回复 ／ 1 页 [
]
|
|
|
|
|
|
框架束缚了OO思维吗？
|
发表: 2007年10月19日 20:48
|
回复
|
|
最近在用ibatis.net开发电子商务网，架构借用了ibatis官方网发布的示例Npetshop：
一、拥有一系列贯穿整个系统的领域模型（Domain）
二、持久层完成领域对象的持久化操作，直接和数据库进行交互（通过 IBatisnet进行映射）
三、服务层对持久层进行封装，进行领域对象的操作
四、表现层
五、UI界面
Domain是整个系统的基础,其抽象出了整个系统的领域对象,当然这里抽象出来的领域对象其实是不完全的,只是作为了没有包含行为的数据载体,通过外部的行为对其进行操作.
数据持久化层采用了Ibatisnet系列组件,使用了DAO对象,该对象为数据访问层提供了统一的访问接口,可以和ADO.net \ NHibernate \ Ibatisnet SqlMapper等协同完成数据访问任务,屏蔽了底层数据映射,并且支持扩展。
Service层对数据持久层进行了封装，主要完成一些针对对应的Domain对象的行为，这一层使用统一的DAO进行操作，完成业务行为
表现层定义了与界面操作相关的后台实现，其行为主要是针对界面操作的，该层调用Service层的业务方法完成界面操作
开发过程中，导致这样一种结果：由于Domain层是数据的载体。所以先设计好数据库表关系，一张表一个实体，然后持久化层写一个对该实体进行增，删，查，改的接口，再写一个类实现该接口（并通过框架机制跟数据库连接），然后Service层对持久层进行了封装，加一些逻辑。
我有一下一些困惑的：
1，是否业务逻辑很简单不需要OO分析与设计，本就是围绕数据库操作，比如会员管理，首先在脑子里显示的是一张数据库关系图，会员，会员类型，会员等级，会员登录纪录表。每张表一个实体，接口就是增，删，查，改，一切都是从数据库开始，建一张表，然后机械的在每一层添加类，不需要OO分析与设计，
2，架构分层清晰，但体会不到灵活性，感觉在做机械的重复。束缚展开OO思维。
[该贴被fety07于2007-10-19 20:53修改过]
|
|
|
|
|
|
re:框架束缚了OO思维吗？
|
发表: 2007年10月20日 10:05
|
回复
|
|
|
|
|
|
|
|
re:框架束缚了OO思维吗？
|
发表: 2007年10月20日 10:16
|
回复
|
|
|
用过ibatis,写一条sql语句,就得写个接口方法,很烦这个
|
|
|
|
|
|
回复:框架束缚了OO思维吗？
|
发表: 2007年10月20日 21:13
|
回复
|
|
>由于Domain层是数据的载体。所以先设计好数据库表关系
首先应该设计好Domain的Model对象，你“所以先设计数据库”？开始方向就走错了，后面就是用框架当然有矛盾不自然了。
看看"建模重要性"中说到：一本书中介绍，没有面向对象的分析，即使使用面向对象的语言运用面向对象的编程也只能开发出似是而非的面向对象的系统，大家觉得有道理吗？
建模的重要性:
http://www.jdon.com/article/17706.html
所以，关键是你业务方法用OO，而不是数据库，脱离数据库分析设计，把数据库只看成是对象保存的一种方法。这样你才能自然使用Java框架。这也是我在Jdon一开始就强调的：领域建模 框架模式一个不能少，领域建模更是首位。
|
|
|
|
|
|
re:框架束缚了OO思维吗？
|
发表: 2007年10月22日 09:35
|
回复
|
|
在<<领域驱动设计>>书中,有这么几段话:
明智地只应用框架中最有价值的部分，降低实现与框架的依赖程度，使以后的设计决策具有更多的灵活性。更重要的是，假设现在的许多框架使用起来非常复杂，这种极简主义会帮助您保持业务对象的可读和可表达。
架构框架和其他工具将会不断地发展。应用中的技术方面会越来越多地在较新的框架中自动完成或者预先制定好。如果能发展到这一步，应用的开发人员将有更多的时间和精力投入到建模核心业务问题上，极大地提高软件生产力和质量。但是当我们朝这个方向发展时，我们必须控制我们对技术解决方案的热衷程度，精细的框架也可能成为应用程序开发人员的束缚。
|
|
|
|
|
|
re:框架束缚了OO思维吗？
|
发表: 2007年10月22日 10:45
|
回复
|
|
感谢banq和各位.我找到了我的缺口,由于还是按照以前的老办法"找名词,写对象",导致了"面向数据表分析",带着寻找突破口的渴望,读了<<领域驱动设计>>,我知道了为什么以前想建领域模型,但模型让人看起来不伦不类,连我自己都不喜欢,看了<<领域驱动设计>>前几章,有点豁然开朗的感觉.
我有一些感悟,请前辈指教:
建领域模型,就像解数学题一样,只有你知道解法时,才能一步步走向结果.当下次再碰上这类问题,就知道这么走.建领域模型时,它也有"解法",这就时建模指导原则,作者总结出了一些模式,知道了指导原则,我们就可以组织对象.当然要熟悉需要经历很多的,就像解数学题一样要多练习.
|
|
|
|
|
|
回复:re:框架束缚了OO思维吗？
|
发表: 2007年10月22日 15:29
|
回复
|
|
从另外一个方面说：就是根据OO设计选择框架，如果一个框架不符合OO分析设计的思路，那么它就是一个不适合OO的框架 。
IBatis从一个极端观点来说就不是一个真正OO框架，也不是一个O/Rmapping框架，它不会强迫你使用OO思维来思考，然后你就用了数据库ER思维，所以，才感觉到"框架束缚了OO思维"。
所以，如果想使自己强迫使用OO思维，选择DDD领域建模性质框架，包括Hibernate这样ORM框架。忘记数据库和数据表概念。
|
|
|
|
|
|
re:框架束缚了OO思维吗？
|
发表: 2007年10月22日 15:55
|
回复
|
|
框架是你要用的工具，OO是你对领域的抽象。
工具不用在应该用的地方，有的时候感觉会妨碍OO，但真正的原因应该是你没有认识到它们的关系。
没有纯OO的框架（如果有，也是不实用的）。
同样，就是处理领域问题，也不一定要全部OO，但你一定要清楚那一部分。
|
|
|
|
|
|
回复:re:框架束缚了OO思维吗？
|
发表: 2007年10月22日 17:22
|
回复
|
|
>同样，就是处理领域问题，也不一定要全部OO，但你一定要清楚那一部分。
由于发现了DDD的魅力,所以解决问题是总是带着如何构建一个领域模型的观念,如果问题简单了,反而持怀疑的态度,这种方案是不是领域模型.其实有一些问题确实很简单,是我把它复杂化了.
[该贴被fety07于2007-10-22 17:23修改过]
|
|
|
|
|
|
回复:回复:re:框架束缚了OO思维吗？
|
发表: 2007年10月23日 15:27
|
回复
|
|
>其实有一些问题确实很简单,是我把它复杂化了
呵呵，不要自责，你勇于反省已经很好，将简单问题复杂化是因为我们以前被灌输的所谓知识阻碍了我们的眼睛，本来很简单质朴的东西，却被数据数学一些高深理性的知识扭曲，DDD有时就是一种生活自觉，这也是你在Evans这本书中找不到类似数学那样公式定理的原因。
|
|
|
|
注册
登陆
上一主题
下一主题
