发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 大数据 扩展性 并发编程 事件驱动 分布式 SOA
1 2 下一页 Go 2

框架束缚了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修改过]

2007-10-20 10:05

你没有熟悉框架机制

2007-10-20 10:16

用过ibatis,写一条sql语句,就得写个接口方法,很烦这个

2007-10-20 21:13

>由于Domain层是数据的载体。所以先设计好数据库表关系
首先应该设计好Domain的Model对象,你“所以先设计数据库”?开始方向就走错了,后面就是用框架当然有矛盾不自然了。

看看"建模重要性"中说到:一本书中介绍,没有面向对象的分析,即使使用面向对象的语言运用面向对象的编程也只能开发出似是而非的面向对象的系统,大家觉得有道理吗?
建模的重要性:
http://www.jdon.com/article/17706.html


所以,关键是你业务方法用OO,而不是数据库,脱离数据库分析设计,把数据库只看成是对象保存的一种方法。这样你才能自然使用Java框架。这也是我在Jdon一开始就强调的:领域建模 框架模式一个不能少,领域建模更是首位。

2007-10-22 09:35

在<<领域驱动设计>>书中,有这么几段话:

明智地只应用框架中最有价值的部分,降低实现与框架的依赖程度,使以后的设计决策具有更多的灵活性。更重要的是,假设现在的许多框架使用起来非常复杂,这种极简主义会帮助您保持业务对象的可读和可表达。

架构框架和其他工具将会不断地发展。应用中的技术方面会越来越多地在较新的框架中自动完成或者预先制定好。如果能发展到这一步,应用的开发人员将有更多的时间和精力投入到建模核心业务问题上,极大地提高软件生产力和质量。但是当我们朝这个方向发展时,我们必须控制我们对技术解决方案的热衷程度,精细的框架也可能成为应用程序开发人员的束缚。

2Go 1 2 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com