[讨论] MVC架构、多层架构同DTO之间的关系。

lihao9806 2004-09-21 09:44:44
目前网上有很多关于MVC架构、多层架构之间的讨论。讨论了很多两种架构的适

用情况,以及两种架构间的对比分析。对于什么是MVC,什么是多层在这里不想多做

讨论了。
在这里主要想向大家谈一谈关于DTO对两种架构的影响。发现在很多相关的讨论

中很少涉及到DTO,感到有些不解。我认为DTO对架构的影响是非常巨大的!目前DTO

大致有以下四种方式:DataSet(RecordSet),XML,Value Object(其实就是一个数据

结构而已),包含CRUD、业务逻辑的领域对象。根据项目的不同规模和不同需要我

们往往要选择一种适合自己的DTO。(关于DTO的选择不在这次讨论之列)

DataSet,XML,VO(Martin Fowler称之为营养不良的领域对象)如果选择了这

三种DTO形式之一时也就决定了你的架构基本上就是以三层来划分的了,因为你的数

据和操作数据的行为是分离的(大家都知道这是违反OO的,因为破坏了封装)于是

你不得不需要一个独立的BLL和DAL。虽然三层要解决问题的初衷并不在此,但是你

的DTO决定了你的架构只能是三层的。MVC则往往变成了这三层中的表示层。

如果选择了包含CRUD、业务逻辑的领域对象,则你的架构整体上才成为真正的

MVC。因为你可以有真正的MODEL。但是这时往往会需要有一个O/R Mapping基础架构

来用作你的数据访问(一般来说除了查询语句外,是不需要由人去写增、删、改SQL

语句的,利用一些简单的技术既可以解决。比如:反射。或选择流行的解决架构。

比如:Hibernate)这时这个基础架构则成了你的数据访问层。换句话说,你的

MODEL和O/R Mapping基础架构共同作为你的BLL和DAL。

无论选择哪种架构要处理的问题不会变少,也不会变的更容易。并且两种架构往

往是你中有我,我中有你的(一个整体,一个局部)。不过,DTO对于你的总体架构是什么起了决定性的

意义,所以选择了DTO的同时也就等于选择了一种总体结构。

小弟不才,抛砖引玉而已,希望大家指正~~~~
...全文
787 点赞 收藏 35
写回复
35 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
Fusuli 2004-10-11
mis98ZB(Effective Typer) 说的好,MVC其实不一定就只能用于表示层,比如同一个类,既是某个类的View,同时也可以是另一个类的Model
回复
xiedong1112 2004-10-10
朋友我有关于mvc架构的报道,如果想知道就把你的e-mail告诉的我,我给你发过去
回复
mis98ZB 2004-10-02
还有,MVC中的M应当看成是服务,而dto只是一个数据的载体,两者不应混为一谈。

还有我觉得MVC不一定就局限于表示层。
表示层的M,可以看成包含其下的业务逻辑层、数据访问层、数据持久层的所有集合。
当然,也可以看成是业务逻辑层提供给它的View而已。
回复
mis98ZB 2004-10-02
呵呵,常看到“M层、V层、C层”这样的东西……
其实MVC跟分层没有关系,要说也只能说是分块。

正如ozzzzzz(希望敏捷)所说:
“原则上说你使用不使用三层结构和你用不用MVC没有什么必然的联系,而且你使用MVC你一样可能是使用了2层的程序结构。”
最典型的例子是M$的MFC。它根本就没有分层的概念。
CView和CFrameWnd是V,负责界面显示。
CDocument是M,用来保存运行时的数据。这个东西比较乱,持久化(Serialize函数)被固定的搭配在里边。
CDocTemplate是C,用来管理CDocument、CView和CFrameWnd。当然,C的另一个重要的功能——消息分发机制,是紧紧地集成在MFC框架里那个奇怪的消息映射机制和命令传递机制中的。

总值MFC作为一个MVC实现的反面教材,在学习方面有非常积极的意义。
了解了MFC,你就能深刻地理解现在的MVC实现(比如说Struts、WebWork)为什么会是现在这个样子。
:)
回复
三合一 2004-09-29
这是本版少有的好帖啊,收藏先

个人觉得DTO跟DAO、JDO这些类似,只是数据获取操作的一种方式,但是使用了它之后确实就不能不根MVC这些模式挂钩,而在其他情况下用的机会是少之又少
回复
pclogic 2004-09-29
UP
回复
ph0enix 2004-09-28
尽管刚刚学习JAVA和OOP,但还是受益匪浅!
有时看高手的讨论一天胜过自己闷书一周!
回复
101monster 2004-09-25
UP!
回复
101monster 2004-09-25
UP!
回复
lihao9806 2004-09-25
感谢大家的参与!(过几天结帖)
回复
flyingbug 2004-09-24
mark
回复
Fusuli 2004-09-23
目前网上有很多关于MVC架构、多层架构之间的讨论
--------------
MVC最多算多层架构的一种,“MVC架构、多层架构之间的讨论”就像马和白马放到一起比较。

MVC最重要的是你能将原来都堆在界面层的一砣分成M、V、C去考虑,这三者除了V是铁定在界面层其他两层不一定就非要说要和什么层对应,这个M可以是一个业务逻辑对象,可以是DTO,可以是datarow甚至是一个结构体,C的情况就更多了。使用MVC之后不一定程序中就有明确的xxModel、xxView、xxController三个对象,往往是由其他类兼职
回复
Fusuli 2004-09-23
DTO的初衷是打包相关的参数或是返回值,尤其是作为远程调用时的返回值,虽然可能只用到其中某些值,但是远程调用来说一次多传点数据以备不时之需要比多次调用划算。所以DTO往往只有简单的setter和getter,因为要远程传递所以DTO还要实现序列化和反序列化以及根据XML创建实例等方法。但是不远程调用时也可以把DTO用来打包参数或是返回值。

面向对象与其说是一种开发技术不如说是一种思维方式,重要的是有OO的思想,有了这种思想语言和规则反而到了其次,当你用这种思想考虑问题时,我想你不会因为某个细节违反了这个法则那个法则而否定你前面整个的思维方式,这些规则不是枷锁而是一种促进,你OO的思想到一定程度回不知不觉的使用这些规则。每设计或编写一段代码就拿出一票规则来套,何必呢

类似的还有MVC、分层架构,这些技术的出现是为了解放我们不是束缚我们,所以说我觉得楼主把这些东西绞到一起就像把自己绑的象螃蟹一样
回复
ozzzzzz 2004-09-22
DIP是说什么的,怎么会成为面向对象的标志了?如果你不遵守DIP,可能你的程序不是一种好的面向对象的方式,但是并不能就说你不是面向对象了。而且依赖倒置可以简化为依赖关系,这样的表达方式会是一种简略的方式?
行为放在一处是当然的,但是是不是这些行为操作的数据也必须和这些行为放在同一位置呢?当然不是了。你的数据是通过数据表达层显示给业务逻辑层的,而你的具体的数据实际是如何存储的是不归业务逻辑层处理的。还是那个球员的例子,比如你的数据库中表格一个球员的数据可能会存放在众多个表中,但是作为一种数据其实只是表示给业务层一个球员类,而其他的业务逻辑都是通过对这个球员类的引用来访问各自的数据。你只知道数据和行为的封装,但是你不知道逻辑、内容、表现的分离原则。
设计模式是不是体现了面向对象的基本原则了呢?你能给我举一个什么样的例子来说明设计模式符合你的那个所谓的封装的原则呢?
什么叫分层,如果你的那个dto可以直通上下,这样还叫分层吗?分层的一个特点就是你不能看到内层内部的东西,你的dto如果从底到上都可以看到还叫分层吗?
回复
ozzzzzz 2004-09-22
lihao9806(李昊)
MVC的那个M不是来自dto,而是来自相邻的那个业务逻辑或者业务服务分层。通过dto传递数据到MVC本身就破坏了分层,就是一种对于封装的不理解。
OCP也好,DIP也罢,只是面向对象设计的基本原则,而不是面向对象必须遵守的法则,更不是所谓的标志。而且要说基础,也是一级OCP为基础,而不是以DIP为基础。而实际上DIP根本就和它所叫的名字不一样,不是什么高层依赖下层,也不是什么下层依赖高层,而是下层和高层都依赖于一个抽象的接口。实际上如果你说DIP是分层的基础原则是可以成立的,但是如果说DIP是面向对象的基本原则,就只能说你是错的。而实际上很多时候根本就没有必要去分层,也没有必要去使用接口,但是是不是这个时候你就能认为你不是在面向对象了呢?
封装主要解决的就是细节依赖问题,而随之必然导致信息的隐藏。而数据和方法是不是要放在一起,对于外面的调用者来说根本就不知道这样的细节,也不能知道这样的细节。逻辑、内容、表现这个方式就是为了更好的把数据和对数据的操作封装在一起而提出的,这两者根本就不是什么比较的问题,而是一个原则,依赖于一个一个方法实现的问题。同时gof是一种很好的实现具体的美学理念的技巧,通过使用gof,可以更加便宜的实现封装。
回复
lihao9806 2004-09-22
关于DIP,就要先说说过程式设计,过程式设计的主要思想是自顶向下、功能分解,

所以高层模块会依赖低层模块,这也是过程式设计的最大缺点。因为高层模块往往

是相对稳定的高介策略,底层模块是解决问题的具体实现,而具体实现往往是比较

容易变动的。为什么高层策略要依赖低层实现呢?面向对象通过抽象来解决这个问

题,使得低层实现可依赖于高层策略,也就是所谓的依赖反转。从而使OCP成为了可

能。DIP是面向对象的主要机制,符合不符合DIP不是一个好不好的问题,恰恰成为

了是不是面向对象的问题,你的依赖关系决定了你的方法是什么,而不是“封装”

之类的概念。“封装”决定了对象存不存在,而不是面向对象的思想。


“数据和行为的封装”与“逻辑、内容、表现的分离原则“这是两个层次面上的东

西,不能放在一起做比较。打算用设计模式来举封装的例子也是如此,根本不是一

个层面上的问题。“逻辑、内容、表现的分离原则“则处于架构范畴。GOF的设计模

式主要是接口的设计模式,处于微观的设计范畴。而封装则是更基础的原则了。在

它们之间相互比较或解释,本身的逻辑就是混乱的。关公战秦琼嘛!

按照你说的,DTO只是在业务逻辑层和数据访问层之间传递,那么表示层的数据呢?

你那个M呢?
回复
rtdb 2004-09-22
> 现在十个人有九个觉得自己懂得OO,实际情况未必如此!!

这句话我特同意。


另外 lihao9806(李昊) 的每句话单独说都是对的,
但连在一起感觉就不是那么回事了。

我认为主要是因为当你用关系数据库时,
请不要总是讲OO。 因为你的核心,你的数据根本不是OO的。
用了那么多的技术与技巧, 也不过是为了将不OO的数据转换成OO而已。
那么这个转换的过程,由于不OO的数据的存在,也不可能是真的OO了。

实际上,关系数据库自有其编程考量与特点,梦想有一个完整的,
自动化的映射成对象的机制, 是不现实的。
从纯OO的角度计论数据库应用也是没有意义的。
回复
ozzzzzz 2004-09-21
DTO是数据,不是model。如果你认为dto是一层的话,那么也只是连接数据存储层和业务层之间的连接层,而不是业务层。
MVC我说过多次了,再重复一次。C是控制页面显示逻辑的,V是显示具体的显示界面,M是需要显示的数据,多数情况下M是业务逻辑层对外的接口。MVC仅仅只是显示的一种框架,而不是一种程序的整体结构的框架。
原则上说你使用不使用三层结构和你用不用MVC没有什么必然的联系,而且你使用MVC你一样可能是使用了2层的程序结构。
回复
lihao9806 2004-09-21
不同的操作数据的行为自然要在不同的地方,否则还叫什么单一职责?

两码事!我说的是同一个操作数据的行为要放在同一个地方,而不要同一个行为到处都有。
-------------------------------------------------------------------------
比如一个球员的数据,会在球员的技术统计这个大职责体系中使用,也会在球员的收入这个大的职责体系使用,还会在球员保险这个体系下使用,是不是按照你的说法就只能有一个球员类了呢?

会有一个球员类,这个类里可能只是一些球员的基本信息及操作。在其他的XX职责体系中会有其他的类,这些类可能依赖也可能关联这个球员类。但是操作球员基本信息的方法不应在这些类里。也就是说,如果球员类是一个DTO的话,它不能是一个VO(单纯的数据类)。
-------------------------------------------------------------------------
设计模式的存在意义和OO的基本特征不挨着吧?我同意:设计模式不重要,重要的是面向对象的基本原则。设计模式只是特定环境下存在的较好的解决方案或范例。
-------------------------------------------------------------------------
依赖是面向对象的标志?不知道你的这个说法来自什么方法学家的什么著作?真的令人费解。

这个是我的问题,说的简略了。依赖倒转法则(DIP)是面向对象的标志。不用问我是谁说的了吧?
-------------------------------------------------------------------------
dto在各层之间传递?这样是分层吗?什么叫外层只依赖内层?一个dto到处跑?再给你强调一次,DTO如果是一层,那么它就是数据层和业务逻辑层之间的那个传递数据的层。

我不认为DTO能算作一层。(如果是它也是“竖”着的一层,其它层是“横”的)DTO不仅在数据层和业务逻辑层之间,而且是跑到要表示层的,否则表示层的数据(MVC中的M)从哪里来?
回复
smallfish2001 2004-09-21
DTO一般会用为SOA框架吧。平常的系统可能用不上它。
回复
加载更多回复
相关推荐
发帖
研发管理
创建于2007-08-27

1221

社区成员

软件工程/管理 管理版
申请成为版主
帖子事件
创建了帖子
2004-09-21 09:44
社区公告
暂无公告