觉得我们公司的框架好变态,求banq点评一下

11-09-11 limcosln1andx
我们公司“首席架构师”自己写了一个mvc框架和一个持久层的框架。配合spring,实现了大部分网站模块。

一,持久层框架

paoding-rose-jade 是一个基于Annotation的数据库访问框架,它支持以接口 + Annotation + SQL 语句的形式,依据开发者的DAO接口在运行时通过java proxy技术创建DAO实例,不需要编写DAO实际实现代码。

于是我们的dao层变成了类似这样:

@DAO(catalog = "example") //catalog是配置数据源的,这个dao就被配置成了处理“example这个数据源”

public interface ExampleDAO {

@SQL("INSERT INTO contact_info (id, user_id, name, phone_code,

create_timestamp) VALUES (:1, :2, :3, :4, :5)")

public int insertContact(int id, int userId, String name, String phoneCode, Date createTime);

}

这里jade框架通过@SQL注释就实现了insertContact方法,并可以给用户自动生成一个exampleDAOBean,只需要

@Autowired

protected ExampleDAO exampleDAO;

注意:DAO接口必须满足以下条件,才能被 paoding-rose-jade 框架识别:

i. 接口应定义在 xxx.yyy.zzz.dao 命名的 Package 下;

ii. 接口命名必须以 "DAO" 结尾;

iii. 接口必须用 "@DAO" Annotation 进行标记。

我个人认为:这虽然看起来省事了(不用自己写dao的实现类),实际上是得不偿失。不如hibernate下大家常用的GenericDao<T>的方式。既然不用写接口的实现类,那接口还有什么意义。这借口和框架耦合的过于紧密了吧。

希望能听听banq对于jade框架这种设计的看法

二,MVC框架

Rose原理概要

Rose 是一个基于Servlet规范、Spring“规范”的WEB开发框架。

Rose 框架通过在web.xml配置过滤器拦截并处理匹配的web请求,如果一个请求应该由在Rose框架下的类来处理, 该请求将在Rose调用中完成对客户端响应. 如果一个请求在Rose中没有找到合适的类来为他服务,Rose将把该请求移交给web容器的其他组件来处理。

Rose使用过滤器而非Servlet来接收web请求,这有它的合理性以及好处。

Servlet规范以“边走边看”的方式来处理请求, 当服务器接收到一个web请求时,并没有要求在web.xml必须有相应的Servlet组件时才能处理,web请求被一系列Filter过滤时, Filter可以拿到相应的Request和Response对象 ,当Filter认为自己已经能够完成整个处理,它将不再调用chain.doNext()来使链中下个组件(Filter、Servlet、JSP)进行处理。

使用过滤器的好处是,Rose可以很好地和其他web框架兼容。这在改造遗留系统、对各种uri的支持具有天然优越性。正是使用过滤器,Rose不再要求请求地址具有特殊的后缀。

为了更好地理解,可以把Rose看成这样一种特殊的Servlet:它能够优先处理认定的事情,如无法处理再交给其它Filter、Servlet或JSP来处理。这个刚好是普通Servlet无法做到的 : 如果一个请求以后缀名配置给他处理时候 ,一旦该Servlet处理不了,Servlet规范没有提供机制使得可以由配置在web.xml的其他正常组件处理 (除404,500等错误处理组件之外)。

以上是公司对于rose的介绍,但我觉得不靠谱,倒像是struts的变异版。或许是因为我对ssh的感情太深,总感觉rose怪怪的。banq能否分析一下这个框架的优缺点。

三,对于海量数据的处理,必须抛弃“面向对象”方法吗

公司是一个互联网公司,具有非常多的用户,海量的数据,需要数据的高可用性和弱一致性。

公司最底层采用mysql集群,表之间没有外键关联,只有逻辑意义上的关联。业务逻辑不使用"事务"。数据的查询要求采用最简单的sql语句,不能使用关联查询和“select *”。

当然这看起来是个处理海量数据的好办法,到目前为止好像很奏效。但我感觉这和我在jdon上学的完全不同。banq经常说分布式计算和nosql是未来的方向,java是最适合分布式计算的平台。banq能否点评一下像我们公司这样处理海量数据的方法有什么优缺点。

好迷茫啊:领域驱动设计,敏捷开发之路到底在哪里?

[该贴被limcosln1andx于2011-09-11 20:04修改过]

[该贴被limcosln1andx于2011-09-11 21:55修改过]

1
banq
2011-09-12 08:11
2011年09月11日 20:03 "@limcosln1andx"的内容
我们公司“首席架构师”自己写了一个mvc框架和一个持久层的框架。配合spring,实现了大部分网站模块 ...

总体来说,这个几个框架确实是有用,Rose框架我以前研究过,人人网开源的。

持久层框架将SQL写在元注释,这和将SQL写入XML的IBatis框架差不多,不过这里可能没有注意到元注释和XML区别,当初JDK 5.0刚出来时我就说了,XML可以不用重新编译代码实现运行现场动态切换,而元注释需要重新编译,这是他们的区别。

DDD观点来看,有查询条件的SQL语句属于一种Specification规格模式,这些规格定义就像规章条文,放在XML中更合适一些。

Rose框架主要是解决页面同时显示多个窗口时(团购网站那种式样),好像是使用JDK并发包实现一个线程一个窗口,那么多个窗口就可以由多个线程完成。因为没有看到这其中实现的重要机制文章,源码也没去研究。这个思路属于Java Protal标准那个时期的思路,将Portal页面在服务器端渲染,实际上现在有了AJAX和REST(如JdonMVC或SpringMVC),Portal的页面都直接放到浏览器中渲染组合,AJAX客户端和REST之间通过JSON小字节传送,即节省流量带宽又快,服务器Share nothing架构负载小。

海量数据抛弃OO说法是片面的,Disruptor并发框架的LMAX团队最近在其博客http://blogs.lmax.com/发布了一篇文章:Modelling Is Everything.意思说,很多人将性能归结各种问题,但是他们认为是业务建模,是面向对象的DDD,如果没有对业务的深入认识,如何根据自己业务作出优化的架构呢?技术上没有银弹,技术狂热者才认为有通用解决方案,这些都是不成熟标志,就像分布式有CAP定理,你一定要搞出CAP都具备的,比如MySQL 5.0,实践证明最后什么也得不到。

至于楼主想敏捷 想MDD,其实可以使用Jdon框架替代Spring,因为你们两个框架一个是表现层一个是持久层,而Jdon是侧重业务层,可以组合成Rose + Jdon + jade 架构。

[该贴被banq于2011-09-13 09:27修改过]

banq
2011-10-16 07:33
2011年09月12日 08:11 "@banq"的内容
对于海量数据的处理,必须抛弃“面向对象”方法吗

公司是一个互联网公司,具有非常多的用户,海量的数据,需要数据的高可用性和弱一致性 ...

见这篇文章:如何打败CAP定理

猜你喜欢