- 浏览: 4820541 次
- 性别:
- 来自: 上海
博客专栏
-
robbin谈管理
浏览量:137001
文章分类
最新评论
-
xly1981:
领导者是团队的灵魂。深入一线的过程,包括代码review,能帮 ...
robbin谈管理:改造团队的经验(2) -
jiehuangwei:
像这种总结比较性的ppt文档可以多发啊
Web并发模型粗浅探讨 -
linux1308:
看完学习到了很多东西,感谢推荐!
推荐一篇很好的RoR部署方案性能评测 -
zweite:
直接对搜索的结果进行缓存是不是会更快一点呢
漫谈应用缓存的命中率问题 -
kaogua:
现在已经是ruby2.0了, 不知道这个的效率是怎么样的, 是 ...
Ruby作为服务器端应用已经成熟了
陶文发起的对领域模型的最新讨论:领域模型的价值与困境,在这个讨论当中,我的关注点是,在现在的技术水平下,我们如何把领域模型的理论和我们实际应用开发框架结合起来,总结出最佳实践:
第一、DAO层和TransactionScript层是邪恶的!
我们在2004年一直跨度到2007年讨论来讨论去,其实都有一个隐含的前提条件:你的领域模型终究无法脱离对DAO层的依赖,以及需要TransactionScript层的包裹。而这样一来,领域模型的通用性、可移植性、业务逻辑的表达能力基本全部丧失,沦为框架限制下的奴隶。
而我们看看现在Java领域的技术进步,JPA已经普及,EJB3的隐含事务管理,甚至连Spring也可以简化成@Transactional,现在已经是我们可以去掉DAO和TransactionScript的时代了。
第二、Seam在消除了DAO层和TransactionScript以后,领域模型的感觉已经呼之欲出
这个不用多说,大家自己去看Seam文档好了。我唯一想强调的是entity bean和business bean分开有没有必要性,我的看法是有必要!这还是和Java本身语言的限制有关系:
1、Java语法表达能力有限,entity bean又不得不弄一大堆getter/setter方法,都放在一个class里面,代码的可阅读性非常差
2、business bean的很多业务逻辑方法需要容器环境,不像Rails的model可以直接mixin进来
3、Java做为目前最主流的工业语言,开发团队都是大规模编码协作的,你都放在一个class里面,团队协作会遇到很大的麻烦(事实上RoR现在也有这样的问题,但是RoR开发效率高,往往不需要那么大规模的开发团队)
3、领域模型不同类别的业务逻辑可以很容易的分到几个不同的business bean里面,这样对团队协作的好处很大。
第三、不考虑框架限制,All-in-One的领域模型好不好?
比方说RoR的model就是All-in-One的,但是一旦出现可以抽象出来,比较通用的业务逻辑,我们还是会把这些逻辑抽出来,单独实现,然后再mixin回去。所以没有必要All-in-One,根据你的实际需要来决定放在一个class里面,还是拆开成几个class。
所以最终我对这个问题的总结就是:
一、只要技术框架能够实现,尽量使用领域模型
二、无论Java还是Ruby,必须消灭DAO和TransactionScript
三、领域模型不必All-in-One,Java可以分割为 1个entity bean和几个business bean,而Ruby可以分割为1个model和几个mixin的module。
http://pig345.iteye.com/blog/79822
= =||莫非是楼上???
使用accessor跟Java语法表达能力有什么关系呢?包含accessor的作用很多,将对于属性变为private,可以通过是否创建accessor来觉得其读写性;包含验证代码;一些Domain Logic。当然嫌麻烦,或者本来所有的属性就都是可以读写的,并且不包含任何业务逻辑,未来也肯定不会包含,那就把属性的可见性改为public也OK了
开发效率高和团队规模之间有必然联系吗?业务巨复杂的ERP,从语言层面上讲,差别已经不大了,特别是将Spring+Hibernate Mix好之后,基本上只需要写业务逻辑就OK了。但就是那巨烦人巨多的业务逻辑,你就是用自然语言写都得写好几天。
这和你去掉DAO又有什么关系?
如果你的程序中到处都是一个业务方法中挤满了dao1.get(1); dao2.save(0),那只能说dao被滥用,或者是设计太糟糕了,这并不是dao的错误。
dao和depository是一个东西,dao模式被人广为知道可能是因为J2EE模式,而depository是因为DDD,于是dao从领域建模角度是有现实对照物的,而非一个纯虚构。
另外,dao可以屏蔽掉数据持久化的实现,我们经常会遇到Hibernate出现瓶颈,改为jdbc+sql实现,改为jdbc+存储过程实现,我现在在改一个东西是将数据库持久化改为xml持久化。
这种分离是非常必要的:
1 技术需要(数据库替换,持久化框架更换,技术变迁,持久介质变化)
2 性能检测。可以非常容易的找到性能瓶颈,起码你可以单独去测数据访问代码和Java程序到底谁是瓶颈
3 异常转换。在DAO层统一异常类型,就像Spring做的那样
4 业务需要。持久化图书,到底应该是book.add,还是把book放进book depository(用Google金山词霸查到的书库一词)呢?bookDepository.add(book)。只不过在J2EE模式中叫成dao了,就成了bookDao.save(book)。因此按照领域建模,dao也是其中的一部分,然后在它里面,包含了内存到持久化设备转换的代码(比如保存到数据库里,保存到本地文件,上传到远程服务器,刻录到DVD,导成磁带)
DAO层为什么是邪恶的,假如DAO仅仅是CRUD加上基础查询功能,那么它是“整齐”的,可“归类”的,看不出有什么邪恶的地方。
如果设计得好的话,唯一和领域模型相交的可能就是那些findByXXX方法了(findById不算,因为每个entity都应该有个ID,是通用的)。但换个设计,假设XXX没有组合式业务语义(例如:PersonInSellDivision销售部员工,由销售部和员工两个语义实体组成),仅仅是property名,
那这些findByXXX方法也算是“整齐”的(findByName等)。这里唯一要确定的是你的一个DAO对应一个entity,避免“污染”。
剩下的组合条件怎么办?如果你是基于Hibernate的就用DetachedCriteria吧。如果你想抽象一层,就用你自己的Condiction类,再根据系统生成DetachedCriteria还是HQL还是SQL。那你的DAO就变为针对单个实体的CRUDF了,F除了基本的Property查找就是组合条件查找了。
那JOIN查找怎么办?entity之间的关系应该是在数据库建模的时候就应该确定,那它就能映射到ORM上。如果用Hibernate的话用DetachedCriteria
就可以很好的完成了(只是觉得奇怪,为什么没人发觉DetachedCriteria的价值?).
如果一个DAO针对一个entity是“干净”的,那它远称不上邪恶。
至此,一个整齐干净的DAO,那一个entity转换一个DAO的对于一个精通JAVA的人来说根本不是问题,甚至不用人手,写个工具就可以完成。
把DAO整干净的行为我不知道算不算是COC?呵呵
TransactionScript应该抽象到容器上去,spring也是沿用了ejb的做法的,只是更易于配置。个人认为这也是Spring2.0之后不予余力地引入AspectJ切面描述的原因。对于AOP和OOP相辅相成的世界。既然TransactionScript那么邪恶,那就由AOP这把利刃管着吧。
第二、Seam在消除了DAO层和TransactionScript以后,领域模型的感觉已经呼之欲出
这个不用多说,大家自己去看Seam文档好了。
说说Seam,我的感觉是一个给annotation严重污染的,极度分散的框架。它不是消灭了DAO而是把DAO切成小块,装自己身上去了,一个弗兰肯斯坦。。。。em.createQuery("select msg from Message msg order by msg.datetime desc")。我看不出DAO给消灭痕迹。
说是依赖注入,我看是依赖查找,@PersistenceContext,@Logger,@XXX。原来查找的代码放到annotation上了。缩短了写法,本质一样。假如我用几个数据库几个PersistenceContext,是不是要区分@PersistenceContext(contextName=xxxx),contextName是我硬造的。
依赖注入只是手段,只是注入过程由一个容器的配置式去管理,配置式可以是XML和annotation,但从集中管理配置这个角度上看,annotation天生就不是集中管理的料,所以我说“极度分散”。只有配置被管理起来,而不是程序员自己分散地写着annotation(不妨设想一下一个被误用的annotation,你要找多少个Java文件来修改,annotation那么多,被误用的机会多着呢),才能称得上是依赖注入,否则都是“伪依赖注入”。
在这方面,我还看不到能替代XML的方案,唯一需要注意的是XML可以自定义任何标签,所以XML配置必须归纳为很少的几个标签,这样才不会让写配置的人精神高度紧张。反正我的脑袋不是赖昌星的脑袋,记不住几个电话号码,也记不住几个标签。
用annotation来实现那些script的灵活的功能.我只想强调的是,script是集中管理逻辑过程的描述语言,和annotation天生的分散特性是相悖的。
annotation超过10个,那它就是一门手艺,超过20个,那它就是一幅20个环的镣铐了。个人以为annotation只有用到基类和父类上才能真正显示它的威力。
Gavin King好好的,干嘛不整Hibernate而整Seam。
1、Java语法表达能力有限,entity bean又不得不弄一大堆getter/setter方法,都放在一个class里面,代码的可阅读性非常差
约定getter/setter是Java的长处,是java的COC,没有这个根本不会有spring,spring的注入就是setter注入。entity bean的setter和getter基本上不是用来注入容器里来的对象的。通常setter和getter都放在开头或者结尾的,根本就不用去阅读,你心里知道有就可以了,甚至都不用它们,它们是给ORM或容器或框架操作的Handler。
而business bean的setter是为参与business上下文过程的功能对象做准备的。
Java是个对象设计语言,所以表述对象之间的关系不是它的长处,它们之间的关系表述和相互作用,用script语言来做再适合不过。Java的script包和OSGi模型就是要引入就是要解决这样的问题的。
用一个简单的语言来描述一个复杂的过程是发展方向。而用复杂的语言描述复杂的东西,复杂的语言描述简单的东西,都不是什么好事。
第三、不考虑框架限制,All-in-One的领域模型好不好?
比方说RoR的model就是All-in-One的,但是一旦出现可以抽象出来,比较通用的业务逻辑,我们还是会把这些逻辑抽出来,单独实现,然后再mixin回去。所以没有必要All-in-One,根据你的实际需要来决定放在一个class里面,还是拆开成几个class。
这点,我还是挺赞同的。编程就是一种在集中和分散之间取舍的艺术。
netbaixc@gmail.com 写道
呵呵,职责单一了不就是应对变化啦?具体说,就是一个类就干这个活,不要干A还干B,否则如果仅仅干A的方式改了你就得去改这个类,重新部署测试;DAO就负责持久化的活,像你说的,如果数据库不同了持久化方式要改变则就改DAO;DOMAIN就负责业务逻辑,比如某个财务数据的计算方式变了,就改DOMAIN;Service负责完成用户和系统的基本交互;Command则是针对所有类型的用户交互的服务,因为有些时候有那种“快捷按钮”,你一点就要求系统给你做“一串”处理,所以Command就可以组织发起几个Service。这样按这种分类标准划分的类,哪个方面要变化,就改哪个方面啦。职责似乎可以无限细分下去,这取决于你对变化的预期,如果我预期存储方式99.9%不会变,我是不是就可以先不考虑用一层DAO呢?我做一个web应用,现在也用不着command,没有撤销前进的功能。当然我还是主张职责单一的,我只是不主张无谓的分层。
DAO和DOMAIN看上去不是界限分明的,很明显地为了提高效率往往把可以java运算的业务逻辑用复杂sql表达,相应的domain就架空了,这时domain的方法就直接调用一下dao对象的方法即可,当然有时候可能要发个邮件短信什么的,那指定是不能放到dao里的。DOMAIN和SERVICE也不是界限分明的。但是其实分层的意义在于它是和整个软件工程协作的。我们做软件时总是先定义需求用例,这时候能够划分出command,再从中抽象提炼出service来供command组合调用。一般情况下用户和系统的交互用例都需要事务保护,自然而然地service层里就会体现事务保护,有时还有业务锁同步逻辑。当我们再往下到概要设计时,就会从service里抽象出很业务的domain出来,每个domain都面向比较稳定的业务职责,相互之间也是可以组合调用的,统一交给service来组合调用,这里多数情况又会发现一个service基本上就是调用一个domain,“界限也不是那么分明,何必分层呢”,最后到详细设计实现时那些数据库的活就从domain里明确出来,自然而然地就出来了dao层,当然这时多数情况下又发现一个domain就是调用一个dao拉到,又何必分层呢?呵呵,比较绕。其实分层是这个过程自然的结果,既然这个过程自然产生了分层,何必要抹杀这个成果呢?毕竟分层达到了良好的OO效果,利用代码可读性可维护性,在IOC环境下更加明显。但我其实开始想说的是必须要有辅助工具来帮助程序员面对一个现实,就是这样的分层产生了太多类文件,对于开发人员手工开发起来一不小心打错个字符啥的,还要命名那么多方法,太辛苦啦,开发人员又觉得没有创造性太八股,很难管理啦!虽然设计和需求人员觉得总算可以通过非编程语言和开发人员交流(限制其创造性)了!
呵呵,职责单一了不就是应对变化啦?具体说,就是一个类就干这个活,不要干A还干B,否则如果仅仅干A的方式改了你就得去改这个类,重新部署测试;DAO就负责持久化的活,像你说的,如果数据库不同了持久化方式要改变则就改DAO;DOMAIN就负责业务逻辑,比如某个财务数据的计算方式变了,就改DOMAIN;Service负责完成用户和系统的基本交互;Command则是针对所有类型的用户交互的服务,因为有些时候有那种“快捷按钮”,你一点就要求系统给你做“一串”处理,所以Command就可以组织发起几个Service。这样按这种分类标准划分的类,哪个方面要变化,就改哪个方面啦。
职责似乎可以无限细分下去,这取决于你对变化的预期,如果我预期存储方式99.9%不会变,我是不是就可以先不考虑用一层DAO呢?我做一个web应用,现在也用不着command,没有撤销前进的功能。
当然我还是主张职责单一的,我只是不主张无谓的分层。
为什么要分层呢?——大部分人是为了分层而分层,比如我们以前的一个做法就是强制一个实体对应一个dao、一个service一个action等等,就像是写八股文章,还美其名曰规范化,为了以后好维护。结果都是一两行的代码在几层之间包来包去。我觉得分层最主要的目的是解耦。很多人可能觉得分层是为了分类职责,这可能是分层带来的一个好处,但不是主要目的。要的目的是解耦,解耦的主要目的是应对变化。比如我分一个dao层,可以屏蔽掉hibernate或jpa或jdbc的具体实现,这样我可以切换不同的实现了。你看spring里边的petstore例子提供了不同的实现。问题是对于变化我们应该什么态度。我觉得应该在三个方面考虑:1.变化发生的可能性和机率;2.提前准备应对这个变化要增加的成本(包括机会成本)3.如果不提前考虑这个变化,以后通过重构来应对的代价。比如你有多大的可能要切换hibernate到jdbc或其他的实现呢?如果hibernate已经被证实足够稳定,那依赖它有什么问题呢?就像你依赖java.util一样是吧。这种被Rod JSon成为“幻影需求”提前为此而分层实在不值得吧。其实就算你分了层以后切换的时候还是会有很多问题的,除非你的应用就像petstore一样简单。所以与其这么做,不如完善你的测试,如果变化来了,有测试做保障,提炼重构付出的代价不一定比你提前预防这种变化的的代价要大很多。而且一定要考虑这种变化的机率的大小。分层的另一个好处是可以做孤立测试,说白了就是分离职责然后单独测试。但我前面说过分离职责不一定要分层的,你可以把业务复杂职责单一的功能放在另外一个类中。我现在的做法是用spring web flow做控制层,不需要java代码,只要xml的flow定义,其中调用service层。这个service层负责事务边界也代理业务,直接使用JPA接口。domain对象除了jpa等元数据的映射,提供一些get方法(我是说计算方法,比如getTotalSize()),还提供一些验证逻辑。页面使用Rich Faces。service测试大部分不做mock,而是连接数据库做测试,spring test框架支持自动回滚,可以用dbunit初始化测试数据就可以了。业务计算复杂的提炼出一个类来可以做mock测试了。可能以后还想加上selenium做验收测试,现在还没有加。
呵呵,职责单一了不就是应对变化啦?具体说,就是一个类就干这个活,不要干A还干B,否则如果仅仅干A的方式改了你就得去改这个类,重新部署测试;DAO就负责持久化的活,像你说的,如果数据库不同了持久化方式要改变则就改DAO;DOMAIN就负责业务逻辑,比如某个财务数据的计算方式变了,就改DOMAIN;Service负责完成用户和系统的基本交互;Command则是针对所有类型的用户交互的服务,因为有些时候有那种“快捷按钮”,你一点就要求系统给你做“一串”处理,所以Command就可以组织发起几个Service。这样按这种分类标准划分的类,哪个方面要变化,就改哪个方面啦。
数据库+展现,剩下的一概不要
你这样不就是分了一层么?“展现”就是你的分层,你的展现如何实现?再分层么?呵呵。
数据库+展现,剩下的一概不要
不同意,除非你的业务逻辑都是单纯增删改查
分层未必代码量大,完全是看你打算把什么东西分层,如何分层和分层的粒度问题。有时候更多的是逻辑上的分层,甚至于可以理解为编程规范,分得好或者说理解的好的话,不会增加多少代码和配置的。
第一、DAO层和TransactionScript层是邪恶的!
我们在2004年一直跨度到2007年讨论来讨论去,其实都有一个隐含的前提条件:你的领域模型终究无法脱离对DAO层的依赖,以及需要TransactionScript层的包裹。而这样一来,领域模型的通用性、可移植性、业务逻辑的表达能力基本全部丧失,沦为框架限制下的奴隶。
而我们看看现在Java领域的技术进步,JPA已经普及,EJB3的隐含事务管理,甚至连Spring也可以简化成@Transactional,现在已经是我们可以去掉DAO和TransactionScript的时代了。
第二、Seam在消除了DAO层和TransactionScript以后,领域模型的感觉已经呼之欲出
这个不用多说,大家自己去看Seam文档好了。我唯一想强调的是entity bean和business bean分开有没有必要性,我的看法是有必要!这还是和Java本身语言的限制有关系:
1、Java语法表达能力有限,entity bean又不得不弄一大堆getter/setter方法,都放在一个class里面,代码的可阅读性非常差
2、business bean的很多业务逻辑方法需要容器环境,不像Rails的model可以直接mixin进来
3、Java做为目前最主流的工业语言,开发团队都是大规模编码协作的,你都放在一个class里面,团队协作会遇到很大的麻烦(事实上RoR现在也有这样的问题,但是RoR开发效率高,往往不需要那么大规模的开发团队)
3、领域模型不同类别的业务逻辑可以很容易的分到几个不同的business bean里面,这样对团队协作的好处很大。
第三、不考虑框架限制,All-in-One的领域模型好不好?
比方说RoR的model就是All-in-One的,但是一旦出现可以抽象出来,比较通用的业务逻辑,我们还是会把这些逻辑抽出来,单独实现,然后再mixin回去。所以没有必要All-in-One,根据你的实际需要来决定放在一个class里面,还是拆开成几个class。
所以最终我对这个问题的总结就是:
一、只要技术框架能够实现,尽量使用领域模型
二、无论Java还是Ruby,必须消灭DAO和TransactionScript
三、领域模型不必All-in-One,Java可以分割为 1个entity bean和几个business bean,而Ruby可以分割为1个model和几个mixin的module。
评论
31 楼
flyzht
2012-04-11
是否用领域模型和具体技术无关,领域模型就是POJO,就是没有任何技术,只用JDBC和JSP一样用领域模型
30 楼
flyzht
2012-04-11
29 楼
sunshineparasol
2010-12-06
肉饼真是大神!!
28 楼
pig345
2009-12-14
http://pig345.iteye.com/blog/79822
27 楼
zorwi
2009-07-11
netbaixc_gmail_com 写道
robbin,大概看了那几个“血型”,嘿嘿,以前呆在国内一个知名公司里,平台是基于spring开发的,就要求分层,service里是描述事务和对外的门面,domain是针对业务的逻辑处理,dao是数据库操作,至于你说的domain object,是简单JAVA对象.当时的开发真是麻烦啊,尤其是要求不能跨层调用,就是command(响应http request)->service->domain->dao,而且这些都是通过spring的IOC配置在XML中,哇塞,那个配置文件看得人是头晕眼花,开发个CRUD那是一个痛苦啊,公司虽然提供了代码机来生成,可是也蛮麻烦的,让人忍不住想,这么搞有么价值?因为庞大的代码和配置文件,使得在开发和维护过程中需要阅读太多的东西了。虽然这些文件确实因为OO而变得职责单一,但是文件太多了,看起来也很费劲的!
说分层也好,说OO划分单一职责也好,不就是希望提高开发效率,利于后期维护么?但是如果分得太细,就会导致代码庞大;如果想要精简代码,有人说就得all-in-one。许多人在这个权衡上争辩,其实有一些更好的想法反而被埋没了,特此拍砖。
1.可以划分得越细越好,涨血到爆血,但是要伴随提供一个图形化的IDE,开发者使用IDE开发,将那么庞大的文件通过工具精简透明掉,开发人员在开发思路上仍然保持清晰的划分,但实际开发和维护通过图形化的向导啊之类的工具帮助来实现。现在很多中间件厂商都有提供哦。
2.采用元数据。记得有个技术公司的技术总监提点我:“小伙子,你看我们的项目,里面的代码不都是在描述业务么?什么校验,什么计算,什么查询”。其实可以将这些业务规则用纯数据来描述,按关系数据表来细粒度管理,然后通过一个框架式的代码来读取这些数据,进行“解析式”执行。这里的数据才是最精简的代码。
说分层也好,说OO划分单一职责也好,不就是希望提高开发效率,利于后期维护么?但是如果分得太细,就会导致代码庞大;如果想要精简代码,有人说就得all-in-one。许多人在这个权衡上争辩,其实有一些更好的想法反而被埋没了,特此拍砖。
1.可以划分得越细越好,涨血到爆血,但是要伴随提供一个图形化的IDE,开发者使用IDE开发,将那么庞大的文件通过工具精简透明掉,开发人员在开发思路上仍然保持清晰的划分,但实际开发和维护通过图形化的向导啊之类的工具帮助来实现。现在很多中间件厂商都有提供哦。
2.采用元数据。记得有个技术公司的技术总监提点我:“小伙子,你看我们的项目,里面的代码不都是在描述业务么?什么校验,什么计算,什么查询”。其实可以将这些业务规则用纯数据来描述,按关系数据表来细粒度管理,然后通过一个框架式的代码来读取这些数据,进行“解析式”执行。这里的数据才是最精简的代码。
= =||莫非是楼上???
26 楼
sslaowan
2009-03-05
引用
1、Java语法表达能力有限,entity bean又不得不弄一大堆getter/setter方法,都放在一个class里面,代码的可阅读性非常差
使用accessor跟Java语法表达能力有什么关系呢?包含accessor的作用很多,将对于属性变为private,可以通过是否创建accessor来觉得其读写性;包含验证代码;一些Domain Logic。当然嫌麻烦,或者本来所有的属性就都是可以读写的,并且不包含任何业务逻辑,未来也肯定不会包含,那就把属性的可见性改为public也OK了
引用
事实上RoR现在也有这样的问题,但是RoR开发效率高,往往不需要那么大规模的开发团队
开发效率高和团队规模之间有必然联系吗?业务巨复杂的ERP,从语言层面上讲,差别已经不大了,特别是将Spring+Hibernate Mix好之后,基本上只需要写业务逻辑就OK了。但就是那巨烦人巨多的业务逻辑,你就是用自然语言写都得写好几天。
引用
Spring也可以简化成@Transactional
这和你去掉DAO又有什么关系?
如果你的程序中到处都是一个业务方法中挤满了dao1.get(1); dao2.save(0),那只能说dao被滥用,或者是设计太糟糕了,这并不是dao的错误。
dao和depository是一个东西,dao模式被人广为知道可能是因为J2EE模式,而depository是因为DDD,于是dao从领域建模角度是有现实对照物的,而非一个纯虚构。
另外,dao可以屏蔽掉数据持久化的实现,我们经常会遇到Hibernate出现瓶颈,改为jdbc+sql实现,改为jdbc+存储过程实现,我现在在改一个东西是将数据库持久化改为xml持久化。
这种分离是非常必要的:
1 技术需要(数据库替换,持久化框架更换,技术变迁,持久介质变化)
2 性能检测。可以非常容易的找到性能瓶颈,起码你可以单独去测数据访问代码和Java程序到底谁是瓶颈
3 异常转换。在DAO层统一异常类型,就像Spring做的那样
4 业务需要。持久化图书,到底应该是book.add,还是把book放进book depository(用Google金山词霸查到的书库一词)呢?bookDepository.add(book)。只不过在J2EE模式中叫成dao了,就成了bookDao.save(book)。因此按照领域建模,dao也是其中的一部分,然后在它里面,包含了内存到持久化设备转换的代码(比如保存到数据库里,保存到本地文件,上传到远程服务器,刻录到DVD,导成磁带)
25 楼
sundoctor
2009-01-04
看了大家说了这么到, 我也说两够,我是不赞成一味追求分层的,我更喜欢No DAO,No Interface方式开发。
24 楼
chaotienhisang
2008-12-22
不要将问题单纯化、该不该消亡和存在都是现实需求牵引的、技术只是服务的是放在二位考虑的
23 楼
llade
2008-12-06
robbin 写道
第一、DAO层和TransactionScript层是邪恶的!
DAO层为什么是邪恶的,假如DAO仅仅是CRUD加上基础查询功能,那么它是“整齐”的,可“归类”的,看不出有什么邪恶的地方。
如果设计得好的话,唯一和领域模型相交的可能就是那些findByXXX方法了(findById不算,因为每个entity都应该有个ID,是通用的)。但换个设计,假设XXX没有组合式业务语义(例如:PersonInSellDivision销售部员工,由销售部和员工两个语义实体组成),仅仅是property名,
那这些findByXXX方法也算是“整齐”的(findByName等)。这里唯一要确定的是你的一个DAO对应一个entity,避免“污染”。
剩下的组合条件怎么办?如果你是基于Hibernate的就用DetachedCriteria吧。如果你想抽象一层,就用你自己的Condiction类,再根据系统生成DetachedCriteria还是HQL还是SQL。那你的DAO就变为针对单个实体的CRUDF了,F除了基本的Property查找就是组合条件查找了。
那JOIN查找怎么办?entity之间的关系应该是在数据库建模的时候就应该确定,那它就能映射到ORM上。如果用Hibernate的话用DetachedCriteria
就可以很好的完成了(只是觉得奇怪,为什么没人发觉DetachedCriteria的价值?).
如果一个DAO针对一个entity是“干净”的,那它远称不上邪恶。
至此,一个整齐干净的DAO,那一个entity转换一个DAO的对于一个精通JAVA的人来说根本不是问题,甚至不用人手,写个工具就可以完成。
把DAO整干净的行为我不知道算不算是COC?呵呵
TransactionScript应该抽象到容器上去,spring也是沿用了ejb的做法的,只是更易于配置。个人认为这也是Spring2.0之后不予余力地引入AspectJ切面描述的原因。对于AOP和OOP相辅相成的世界。既然TransactionScript那么邪恶,那就由AOP这把利刃管着吧。
robbin 写道
第二、Seam在消除了DAO层和TransactionScript以后,领域模型的感觉已经呼之欲出
这个不用多说,大家自己去看Seam文档好了。
说说Seam,我的感觉是一个给annotation严重污染的,极度分散的框架。它不是消灭了DAO而是把DAO切成小块,装自己身上去了,一个弗兰肯斯坦。。。。em.createQuery("select msg from Message msg order by msg.datetime desc")。我看不出DAO给消灭痕迹。
说是依赖注入,我看是依赖查找,@PersistenceContext,@Logger,@XXX。原来查找的代码放到annotation上了。缩短了写法,本质一样。假如我用几个数据库几个PersistenceContext,是不是要区分@PersistenceContext(contextName=xxxx),contextName是我硬造的。
依赖注入只是手段,只是注入过程由一个容器的配置式去管理,配置式可以是XML和annotation,但从集中管理配置这个角度上看,annotation天生就不是集中管理的料,所以我说“极度分散”。只有配置被管理起来,而不是程序员自己分散地写着annotation(不妨设想一下一个被误用的annotation,你要找多少个Java文件来修改,annotation那么多,被误用的机会多着呢),才能称得上是依赖注入,否则都是“伪依赖注入”。
在这方面,我还看不到能替代XML的方案,唯一需要注意的是XML可以自定义任何标签,所以XML配置必须归纳为很少的几个标签,这样才不会让写配置的人精神高度紧张。反正我的脑袋不是赖昌星的脑袋,记不住几个电话号码,也记不住几个标签。
用annotation来实现那些script的灵活的功能.我只想强调的是,script是集中管理逻辑过程的描述语言,和annotation天生的分散特性是相悖的。
annotation超过10个,那它就是一门手艺,超过20个,那它就是一幅20个环的镣铐了。个人以为annotation只有用到基类和父类上才能真正显示它的威力。
Gavin King好好的,干嘛不整Hibernate而整Seam。
robbin 写道
1、Java语法表达能力有限,entity bean又不得不弄一大堆getter/setter方法,都放在一个class里面,代码的可阅读性非常差
约定getter/setter是Java的长处,是java的COC,没有这个根本不会有spring,spring的注入就是setter注入。entity bean的setter和getter基本上不是用来注入容器里来的对象的。通常setter和getter都放在开头或者结尾的,根本就不用去阅读,你心里知道有就可以了,甚至都不用它们,它们是给ORM或容器或框架操作的Handler。
而business bean的setter是为参与business上下文过程的功能对象做准备的。
Java是个对象设计语言,所以表述对象之间的关系不是它的长处,它们之间的关系表述和相互作用,用script语言来做再适合不过。Java的script包和OSGi模型就是要引入就是要解决这样的问题的。
用一个简单的语言来描述一个复杂的过程是发展方向。而用复杂的语言描述复杂的东西,复杂的语言描述简单的东西,都不是什么好事。
robbin 写道
第三、不考虑框架限制,All-in-One的领域模型好不好?
比方说RoR的model就是All-in-One的,但是一旦出现可以抽象出来,比较通用的业务逻辑,我们还是会把这些逻辑抽出来,单独实现,然后再mixin回去。所以没有必要All-in-One,根据你的实际需要来决定放在一个class里面,还是拆开成几个class。
这点,我还是挺赞同的。编程就是一种在集中和分散之间取舍的艺术。
22 楼
laiseeme
2008-12-04
以后就四个package
entity
manager
controller
util
entity
manager
controller
util
21 楼
terranhao
2008-12-04
为什么使用seam能消除DAO?
对一些查询,我还是需要一个DAO来封装啊,要不每次需要select e.* from entity as e where...,我都得调用entitymanager来执行这个sql?
如果用dao,我直接注入一个无状态的dao,然后调用dao就可以了,也避免了代码重复啊
期待解答。
对一些查询,我还是需要一个DAO来封装啊,要不每次需要select e.* from entity as e where...,我都得调用entitymanager来执行这个sql?
如果用dao,我直接注入一个无状态的dao,然后调用dao就可以了,也避免了代码重复啊
期待解答。
20 楼
netbaixc_gmail_com
2008-12-03
upheart 写道
netbaixc@gmail.com 写道
呵呵,职责单一了不就是应对变化啦?具体说,就是一个类就干这个活,不要干A还干B,否则如果仅仅干A的方式改了你就得去改这个类,重新部署测试;DAO就负责持久化的活,像你说的,如果数据库不同了持久化方式要改变则就改DAO;DOMAIN就负责业务逻辑,比如某个财务数据的计算方式变了,就改DOMAIN;Service负责完成用户和系统的基本交互;Command则是针对所有类型的用户交互的服务,因为有些时候有那种“快捷按钮”,你一点就要求系统给你做“一串”处理,所以Command就可以组织发起几个Service。这样按这种分类标准划分的类,哪个方面要变化,就改哪个方面啦。职责似乎可以无限细分下去,这取决于你对变化的预期,如果我预期存储方式99.9%不会变,我是不是就可以先不考虑用一层DAO呢?我做一个web应用,现在也用不着command,没有撤销前进的功能。当然我还是主张职责单一的,我只是不主张无谓的分层。
DAO和DOMAIN看上去不是界限分明的,很明显地为了提高效率往往把可以java运算的业务逻辑用复杂sql表达,相应的domain就架空了,这时domain的方法就直接调用一下dao对象的方法即可,当然有时候可能要发个邮件短信什么的,那指定是不能放到dao里的。DOMAIN和SERVICE也不是界限分明的。但是其实分层的意义在于它是和整个软件工程协作的。我们做软件时总是先定义需求用例,这时候能够划分出command,再从中抽象提炼出service来供command组合调用。一般情况下用户和系统的交互用例都需要事务保护,自然而然地service层里就会体现事务保护,有时还有业务锁同步逻辑。当我们再往下到概要设计时,就会从service里抽象出很业务的domain出来,每个domain都面向比较稳定的业务职责,相互之间也是可以组合调用的,统一交给service来组合调用,这里多数情况又会发现一个service基本上就是调用一个domain,“界限也不是那么分明,何必分层呢”,最后到详细设计实现时那些数据库的活就从domain里明确出来,自然而然地就出来了dao层,当然这时多数情况下又发现一个domain就是调用一个dao拉到,又何必分层呢?呵呵,比较绕。其实分层是这个过程自然的结果,既然这个过程自然产生了分层,何必要抹杀这个成果呢?毕竟分层达到了良好的OO效果,利用代码可读性可维护性,在IOC环境下更加明显。但我其实开始想说的是必须要有辅助工具来帮助程序员面对一个现实,就是这样的分层产生了太多类文件,对于开发人员手工开发起来一不小心打错个字符啥的,还要命名那么多方法,太辛苦啦,开发人员又觉得没有创造性太八股,很难管理啦!虽然设计和需求人员觉得总算可以通过非编程语言和开发人员交流(限制其创造性)了!
19 楼
upheart
2008-12-02
netbaixc@gmail.com 写道
呵呵,职责单一了不就是应对变化啦?具体说,就是一个类就干这个活,不要干A还干B,否则如果仅仅干A的方式改了你就得去改这个类,重新部署测试;DAO就负责持久化的活,像你说的,如果数据库不同了持久化方式要改变则就改DAO;DOMAIN就负责业务逻辑,比如某个财务数据的计算方式变了,就改DOMAIN;Service负责完成用户和系统的基本交互;Command则是针对所有类型的用户交互的服务,因为有些时候有那种“快捷按钮”,你一点就要求系统给你做“一串”处理,所以Command就可以组织发起几个Service。这样按这种分类标准划分的类,哪个方面要变化,就改哪个方面啦。
职责似乎可以无限细分下去,这取决于你对变化的预期,如果我预期存储方式99.9%不会变,我是不是就可以先不考虑用一层DAO呢?我做一个web应用,现在也用不着command,没有撤销前进的功能。
当然我还是主张职责单一的,我只是不主张无谓的分层。
18 楼
jerryeye
2008-12-02
DAO做的事情不做了吗?不做了当然取消,做了却取消,只是搬了个地方而已,这样有意思?DAO只是三个字母而已,惹谁了?大概robbin被国外的"血型"弄的迷糊了。
17 楼
netbaixc_gmail_com
2008-12-02
upheart 写道
为什么要分层呢?——大部分人是为了分层而分层,比如我们以前的一个做法就是强制一个实体对应一个dao、一个service一个action等等,就像是写八股文章,还美其名曰规范化,为了以后好维护。结果都是一两行的代码在几层之间包来包去。我觉得分层最主要的目的是解耦。很多人可能觉得分层是为了分类职责,这可能是分层带来的一个好处,但不是主要目的。要的目的是解耦,解耦的主要目的是应对变化。比如我分一个dao层,可以屏蔽掉hibernate或jpa或jdbc的具体实现,这样我可以切换不同的实现了。你看spring里边的petstore例子提供了不同的实现。问题是对于变化我们应该什么态度。我觉得应该在三个方面考虑:1.变化发生的可能性和机率;2.提前准备应对这个变化要增加的成本(包括机会成本)3.如果不提前考虑这个变化,以后通过重构来应对的代价。比如你有多大的可能要切换hibernate到jdbc或其他的实现呢?如果hibernate已经被证实足够稳定,那依赖它有什么问题呢?就像你依赖java.util一样是吧。这种被Rod JSon成为“幻影需求”提前为此而分层实在不值得吧。其实就算你分了层以后切换的时候还是会有很多问题的,除非你的应用就像petstore一样简单。所以与其这么做,不如完善你的测试,如果变化来了,有测试做保障,提炼重构付出的代价不一定比你提前预防这种变化的的代价要大很多。而且一定要考虑这种变化的机率的大小。分层的另一个好处是可以做孤立测试,说白了就是分离职责然后单独测试。但我前面说过分离职责不一定要分层的,你可以把业务复杂职责单一的功能放在另外一个类中。我现在的做法是用spring web flow做控制层,不需要java代码,只要xml的flow定义,其中调用service层。这个service层负责事务边界也代理业务,直接使用JPA接口。domain对象除了jpa等元数据的映射,提供一些get方法(我是说计算方法,比如getTotalSize()),还提供一些验证逻辑。页面使用Rich Faces。service测试大部分不做mock,而是连接数据库做测试,spring test框架支持自动回滚,可以用dbunit初始化测试数据就可以了。业务计算复杂的提炼出一个类来可以做mock测试了。可能以后还想加上selenium做验收测试,现在还没有加。
呵呵,职责单一了不就是应对变化啦?具体说,就是一个类就干这个活,不要干A还干B,否则如果仅仅干A的方式改了你就得去改这个类,重新部署测试;DAO就负责持久化的活,像你说的,如果数据库不同了持久化方式要改变则就改DAO;DOMAIN就负责业务逻辑,比如某个财务数据的计算方式变了,就改DOMAIN;Service负责完成用户和系统的基本交互;Command则是针对所有类型的用户交互的服务,因为有些时候有那种“快捷按钮”,你一点就要求系统给你做“一串”处理,所以Command就可以组织发起几个Service。这样按这种分类标准划分的类,哪个方面要变化,就改哪个方面啦。
16 楼
upheart
2008-12-02
为什么要分层呢?——大部分人是为了分层而分层,比如我们以前的一个做法就是强制一个实体对应一个dao、一个service一个action等等,就像是写八股文章,还美其名曰规范化,为了以后好维护。结果都是一两行的代码在几层之间包来包去。
我觉得分层最主要的目的是解耦。很多人可能觉得分层是为了分类职责,这可能是分层带来的一个好处,但不是主要目的。要的目的是解耦,解耦的主要目的是应对变化。比如我分一个dao层,可以屏蔽掉hibernate或jpa或jdbc的具体实现,这样我可以切换不同的实现了。你看spring里边的petstore例子提供了不同的实现。
问题是对于变化我们应该什么态度。我觉得应该在三个方面考虑:1.变化发生的可能性和机率;2.提前准备应对这个变化要增加的成本(包括机会成本)3.如果不提前考虑这个变化,以后通过重构来应对的代价。
比如你有多大的可能要切换hibernate到jdbc或其他的实现呢?如果hibernate已经被证实足够稳定,那依赖它有什么问题呢?就像你依赖java.util一样是吧。这种被Rod JSon成为“幻影需求”提前为此而分层实在不值得吧。其实就算你分了层以后切换的时候还是会有很多问题的,除非你的应用就像petstore一样简单。所以与其这么做,不如完善你的测试,如果变化来了,有测试做保障,提炼重构付出的代价不一定比你提前预防这种变化的的代价要大很多。而且一定要考虑这种变化的机率的大小。
分层的另一个好处是可以做孤立测试,说白了就是分离职责然后单独测试。但我前面说过分离职责不一定要分层的,你可以把业务复杂职责单一的功能放在另外一个类中。
我现在的做法是用spring web flow做控制层,不需要java代码,只要xml的flow定义,其中调用service层。这个service层负责事务边界也代理业务,直接使用JPA接口。domain对象除了jpa等元数据的映射,提供一些get方法(我是说计算方法,比如getTotalSize()),还提供一些验证逻辑。页面使用Rich Faces。
service测试大部分不做mock,而是连接数据库做测试,spring test框架支持自动回滚,可以用dbunit初始化测试数据就可以了。业务计算复杂的提炼出一个类来可以做mock测试了。
可能以后还想加上selenium做验收测试,现在还没有加。
我觉得分层最主要的目的是解耦。很多人可能觉得分层是为了分类职责,这可能是分层带来的一个好处,但不是主要目的。要的目的是解耦,解耦的主要目的是应对变化。比如我分一个dao层,可以屏蔽掉hibernate或jpa或jdbc的具体实现,这样我可以切换不同的实现了。你看spring里边的petstore例子提供了不同的实现。
问题是对于变化我们应该什么态度。我觉得应该在三个方面考虑:1.变化发生的可能性和机率;2.提前准备应对这个变化要增加的成本(包括机会成本)3.如果不提前考虑这个变化,以后通过重构来应对的代价。
比如你有多大的可能要切换hibernate到jdbc或其他的实现呢?如果hibernate已经被证实足够稳定,那依赖它有什么问题呢?就像你依赖java.util一样是吧。这种被Rod JSon成为“幻影需求”提前为此而分层实在不值得吧。其实就算你分了层以后切换的时候还是会有很多问题的,除非你的应用就像petstore一样简单。所以与其这么做,不如完善你的测试,如果变化来了,有测试做保障,提炼重构付出的代价不一定比你提前预防这种变化的的代价要大很多。而且一定要考虑这种变化的机率的大小。
分层的另一个好处是可以做孤立测试,说白了就是分离职责然后单独测试。但我前面说过分离职责不一定要分层的,你可以把业务复杂职责单一的功能放在另外一个类中。
我现在的做法是用spring web flow做控制层,不需要java代码,只要xml的flow定义,其中调用service层。这个service层负责事务边界也代理业务,直接使用JPA接口。domain对象除了jpa等元数据的映射,提供一些get方法(我是说计算方法,比如getTotalSize()),还提供一些验证逻辑。页面使用Rich Faces。
service测试大部分不做mock,而是连接数据库做测试,spring test框架支持自动回滚,可以用dbunit初始化测试数据就可以了。业务计算复杂的提炼出一个类来可以做mock测试了。
可能以后还想加上selenium做验收测试,现在还没有加。
15 楼
icewubin
2008-12-01
wangchao_17915566 写道
数据库+展现,剩下的一概不要
你这样不就是分了一层么?“展现”就是你的分层,你的展现如何实现?再分层么?呵呵。
14 楼
czx566
2008-12-01
wangchao_17915566 写道
数据库+展现,剩下的一概不要
不同意,除非你的业务逻辑都是单纯增删改查
13 楼
wangchao_17915566
2008-12-01
数据库+展现,剩下的一概不要
12 楼
icewubin
2008-12-01
引用
5. 如果对分层的体系结构熟悉的话,开发效率并不低(虽然代码量较大,但不复杂,易于调
试、测试和实现),可能有点boring,但更易于合作分工。
试、测试和实现),可能有点boring,但更易于合作分工。
分层未必代码量大,完全是看你打算把什么东西分层,如何分层和分层的粒度问题。有时候更多的是逻辑上的分层,甚至于可以理解为编程规范,分得好或者说理解的好的话,不会增加多少代码和配置的。
发表评论
-
WebObjects的来龙去脉
2012-06-08 15:30 7605在知乎上回答的一个问题:http://www.zhihu.co ... -
缓存技术浅谈
2010-09-24 18:08 21799有我在两年前写的一个培训的ppt,是介绍缓存知识的。有兴趣的可 ... -
发现JBoss Seam很棒呀!有用Seam做过项目的吗?
2008-07-06 20:56 30313上周去见了一个朋友Mark,他应邀在Red Hat的研讨会上面 ... -
Spring Application Platform - SpringSource的应用服务器发布
2008-05-05 17:04 68922008年的5.1劳动节,Spring ... -
Warp framework - 一个相当有前途的Java轻量级Web开发框架
2008-03-06 15:24 22553Warp framework 是最近刚刚 ... -
Google Android会成为手机领域的微软Windows吗?
2007-11-16 17:23 9643Google gPhone手机的传言已经沸沸扬扬好几个月了,然 ... -
Java已经过时了吗?
2007-07-02 15:43 59715在四年以前,当我开始 ... -
Java开源框架发展的遐想
2007-05-23 00:04 34810上周末在杭州网侠大会做演讲的时候,我说:Java开源框架的革命 ... -
漫谈应用缓存的命中率问题
2007-05-09 14:19 26450这篇文章源自于: http://www.iteye.com/ ... -
为什么ORM性能比iBATIS好?
2007-05-06 11:16 34517缓存是有很多层次的,有web server前端缓存,有动态页面 ... -
点评Grails vs RoR
2007-03-30 17:49 8285Grails的革新和RoR相比,非常不彻底,很多地方兼容Jav ... -
缓存简述
2007-03-30 09:55 12263缓存实现的层面有很多: 1、对象缓存 由ORM框架提供,透明 ... -
JRuby0.9.8,正式宣布支持ruby on rails
2007-03-07 10:35 15665http://jruby.codehaus.org/ 自从S ... -
domain model的延伸讨论
2007-03-03 01:17 40708domain model,又称为领域模型,是Java企业应用讨 ... -
可以开始用Struts2.0了
2007-02-27 14:56 56099http://struts.apache.org/ Apac ... -
Google Guice - 比Spring快100倍的IoC容器
2007-02-27 14:46 58232http://code.google.com/p/google ... -
Spring2.0和EJB3.0随谈
2007-02-08 14:26 18464Spring自从2003年发布以来 ... -
Java程序员的推荐阅读书籍
2007-02-07 20:12 101364《Java程序员的推荐阅读 ... -
应该如何正确使用Quartz
2006-12-27 11:40 34231对于Web容器来说,最忌讳应用程序私自启动线程,自行进行线程调 ... -
静态类型语言的优势究竟是什么?
2006-11-13 10:03 33485在参与这个讨论的过程中,产生了一个新的话题,很想和大家探讨一下 ...
相关推荐
10. **模型应用**:观点型阅读理解模型可以应用于各种场景,如在线评论分析、社交媒体情绪检测、产品评价总结等。 在提供的压缩包文件中,"基于capsule的观点型阅读理解模型实现"很可能是包含代码、模型结构图、...
总结来说,量化策略专题研究深入探讨了量化行业配置模型的构建和应用,结合最新的观点,为投资者提供了优化投资组合的有效工具。然而,理解和实施量化策略需要扎实的统计学基础、编程技能以及对市场的敏锐洞察,同时...
最后,通过实验验证模型的准确性和泛化能力,并对识别出的垃圾观点文档进行统计和分析,总结出垃圾观点文档的共同特征,这些特征可用于识别新数据集中垃圾观点文档的可能性。在此过程中,还需要讨论如何处理评论中的...
综上所述,本文在机器学习尤其是随机森林模型的应用上提出了创新的改进方法,即通过因子观点的融入来提升模型在金融市场中的灵活性和适用性,这对于金融领域的量化投资具有重要的实践意义和参考价值。同时,它也为...
这可能涉及到对新词汇的识别和其语义关系的推断,确保模型的适应性和时效性。 5. **实时分析**:最后,基于构建的领域语义关系图,对网络社区的短文本数据进行实时分析。这一步骤能够快速捕捉到文本中的关键信息,...
其中,AlexNet作为CNN的一个标志性模型,不仅在2012年的ImageNet大规模视觉识别挑战赛(ILSVRC)中一举夺魁,还因其卓越的表现极大地推动了深度学习领域的发展。 #### 二、背景介绍 四年前,即2008年左右,由Yann ...
数据偏见是指训练数据中存在的偏差,这种偏差可能会导致模型在预测时倾向于某些特定的群体或观点,从而影响模型的公平性和准确性。解决数据偏见的策略包括: - 确保训练数据覆盖广泛的人群、观点和情境。 - 使用统计...
情感分析是自然语言处理(NLP)领域的一个重要任务,旨在识别和提取文本中的主观信息,如情绪、观点和态度。 首先,我们要理解LSTM网络的基本结构。LSTM是一种特殊的循环神经网络(RNN),设计用于解决传统RNN在...
报告总结的核心观点包括:(1) 预计到2025年,AI将在全球范围内产生显著的社会和经济效益;(2) 计算力的快速增长将加速大模型的演进,预计到2028年,市场规模将增长超过1095%;(3) 大模型正逐步解决人工智能在数据...
- **作用**:它有助于减少误解和沟通障碍,确保所有人对系统的需求和设计有着相同的观点。 - **实践方法**: - **词汇表**:创建并维护一个项目词汇表,定义术语和其含义。 - **协作开发**:与业务专家紧密合作,...
IBIS模型广泛应用于项目管理、软件工程、政策制定、教育领域,以及任何需要团队协作和决策的环境。它鼓励开放的沟通,促进理解和共识的形成,同时避免了因信息过载而造成的混乱。 **文档详细内容** "IBIS模型详解...
该白皮书主要围绕人工智能大模型在医疗健康领域的应用进行了详尽的分析,并提出了以下几个关键观点: 1. **应用层面的全面覆盖**:人工智能大模型不仅能够应用于生命科学和医药器械的研发阶段,还能够覆盖医学影像...
本文介绍了一种新的线性估计方法,该方法通过两次AR(自回归)模型的估计来实现对ARMA模型的参数估计。此外,文中还讨论了一维时间序列开环系统与闭环系统的辨识方法及定阶问题,并通过仿真实验验证了该方法的有效性...
在这个领域,观点提取是一项关键任务,它涉及到从大量文本中识别、抽取和总结人们对于特定主题的观点、态度或情感。 观点提取通常包含三个主要步骤:情感极性判断、观点目标识别和观点值量化。情感极性判断是指确定...
【文章内容概述】 本文主要探讨了在GPS高程...通过对实例的分析,作者提出在选择模型参数时,应充分考虑核函数的数量,以实现最优的高程拟合效果。这一研究对于提高GPS在测绘和工程领域的应用精度具有重要的实践意义。
总结而言,通过结合Black-Litterman模型和风险平价组合的方法,投资者能够在考虑风险的同时,合理地融入个人的预期收益率观点,从而在投资组合构建过程中实现更加灵活和定制化的资产配置。这种策略不仅丰富了投资...
如果你了解"模型"的定义是对现实的有选择性的精简,然后用这样的观点去读DDD 这本书,你就会发现,DDD 其实没有什么太多的新鲜玩意,它更多地是可以看作是面向对象思潮的回归和升华。在一个"万事万物皆对象"的世界里...
### 周鸿祎关于大模型趋势语录2024.pdf #### 核心知识点概览 ...通过上述总结可以看出,周鸿祎对于大模型的发展趋势有着深刻的理解,并提出了多个实用的观点和建议,为行业内的企业及创业者提供了宝贵的参考和启示。