我们公司“首席架构师”自己写了一个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能否点评一下像我们公司这样处理海量数据的方法有什么优缺点。
好迷茫啊:领域驱动设计,敏捷开发之路到底在哪里?