- 浏览: 153105 次
文章分类
最新评论
-
飘零雪:
[b][/b][i][/i][u][/u]引用
自定义Mave archetype的创建 -
fujohnwang:
<div class="quote_title ...
基于iBatis的开源分布式数据访问层 -
gzenzen:
<pre name="code" c ...
基于iBatis的开源分布式数据访问层 -
fujohnwang:
bornwan 写道我就很想知道分布式数据源,水平切分之后排序 ...
基于iBatis的开源分布式数据访问层 -
fujohnwang:
gzenzen 写道什么时候支持mybatis3、spring ...
基于iBatis的开源分布式数据访问层
Table of Contents In fact, I found this is a common problem which often happens on novices, I admit that everyone will take a path to grow up, so I am not blaming someone or something, What I just want to do is to share some experiences or personal opinions on similar scenarios, so that others can benefit and prevent from such problems. We are working on a project that uses Netty as our network layer framework, so that also means we accept Netty's API style and design philosophy, that's event-driven style API design. I setup the whole code framework, then split the LUW to team members so that everyone can start to get down to their work details. But when I started to do some code review on other members' code, I found some“surprises” . In order to keep the consistency of the whole code framework, I had designed the API in an event-driven style, but I found the interface which works as a contract between different logical layers had been modified into a style of old procedure ones. To find out the story on this, let's start from the beginning. We have several layers in our design, a networking layer, a data processing layer and other layers. In the network layer, we receive data packets from event source, and then dispatch the events to the data processing layer which will process the event data as per different situations. With such a prerequisite, we can easily declare an interface as the abstraction to the behavior of processing event data, let's call it IEventProcessor: So what u will do with such an interface declaration to abstract proper behaviors as per the above scenario? I don't know what u will do(although I have known what someone had done), but I do design this interface this way: It's not a big deal u may say, but such design is a proper one as per situation we have above. Why? The event consumers(I mean different implementations of IEventProcessor) can only care about the events they are interested, and don't bother with other concerns; Strong-typed API design setup a strong contract for different layers that stands aside each other. The implementations will know as much as they need to know by only the API that's exposed to them. Different concerns are separated to different places. The event dispatching concern, the event-data marshalling concern and the event processing concern, all of them now are taken care of by different parts of the system. In the period of event processing, if we still have other concerns to deal with, for example, monitoring concern, auditing concern and many more, we can separate them into different AOP aspect and manage them well. Of course, I think we can find more benefits from such a style of API design. And I also think this is a clear and clean API design for our system, but someone does not. After code review of some team member's code, I found he not only break the top implementation class, but also break the original IEventProcessor abstraction. The IEventProcessor interface had been changed to: and of course , an implementation is also given: It may seem OKey to u, but believe me, you still have more to do with. Here are some opinions of mine for this: First of all, such a API design or directly say implementation breaks the strong-typed contract of original interface design, and turn to a weak typed one which use primitive type int to distinguish different event types. So as a result, every implementations should know which int values are legal and which ones are not. Since every implementations should know same concerns, every implementations may repeat same works too. If strong typed interface design is given, such redundant things or concerns should not appear. This is where strong-typed languages shine. The implementation involves too much concerns which goes against basic software design principles. It has to take care of dispatching event, auditing event data, and processing event data, etc. A good thing is, the event data marshalling concern is taken care of by different component of the system as I had advised, but we still have too many concerns tangling together here. Although different event types have been handled to different data processing methods, but a deadly problem is, these methods are declared to be private, which means we can't even extend the processing logic by inheriting this class. As a contrast, the original IEventProcessor interface design has even better extension ability. I should say, this is the way we do things in old days, It does work, and can be refactored to have a better structure, but we can do it better. As to how, I think you can find it out or already do.
So What u will do in such scenarios? Which style do you like? Share your opinions and let us all know if you like. I know this topic gets too much into the details of coding level concerns, but I do like such simple topics because you can always extend such topics and gain more if you do think it further from code level to framework level, event to architecture level.
王福强(Darren.Wang) <fujohnwang@gmail.com> 2010-07-12
public interface IEventProcessor {
// TODO
}
public interface IEventProcessor<E> {
void onBeginEvent(E event) throws Exception;
void onJoggingEvent(E event) throws Exception;
void onRunningEvent(E event) throws Exception;
void onSomeEventWeDontCare(E event) throws Exception;
void onOtherEventThatPossible(E event) throws Exception;
}
public interface IEventProcessor{
void onEvent(byte[] eventData, byte eventType) throws Exception;
}
public class EventProcessor implements IEventProcessor<byte[]> {
// fields declarations
public void onEvent(byte[] eventData, byte eventType) throws Exception {
// preconditions checking
byte[] event = ArrayUtils.subarray(eventData, 1, eventData.length);
switch (eventType) {
case EventTypes.EVENT_ONE:
processEventOne(event);
// auditing things
break;
case EventTypes.EVENT_TWO:
processEventTwo(event);
// auditing things
break;
case EventTypes.EVENT_THREE:
processEventThree(event);
// auditing things
break;
case EventTypes.EVENT_FOUR:
processEventFour(event);
// auditing things
break;
case EventTypes.EVENT_FIVE:
processEventFive(event);
// auditing things
break;
default:
break;
}
// other logic
}
private void processEventFive(byte[] event) {
// TODO Auto-generated method stub
}
private void processEventFour(byte[] event) {
// TODO Auto-generated method stub
}
private void processEventThree(byte[] event) {
// TODO Auto-generated method stub
}
private void processEventTwo(byte[] event) {
// TODO Auto-generated method stub
}
private void processEventOne(byte[] event) {
// TODO Auto-generated method stub
}
}
发表评论
-
基于iBatis的开源分布式数据访问层
2011-03-28 11:46 5472http://code.alibabatech.com/wik ... -
分布式数据访问与同步场景浅析
2010-09-06 19:50 2189分布式数据访 ... -
Netty Framework Tips And Gotchas
2010-08-11 18:01 2625王福强(Darren.W ... -
有关Maven编译DeprecatedAPI失败的问题
2010-08-02 10:59 4436在项目代码里用了sun.misc.Signal ... -
Java Daemon Control
2010-07-27 17:50 2866Java Daemon Control ... -
HA狭义与广义论
2010-07-09 09:25 1426Author: Darren Wang(fujohnwang) ... -
Why We Need A Global ID Generator?!
2010-05-18 13:01 1586Table of Contents 1. Pai ... -
Gotchas With JUnit's Execution Model
2010-03-26 09:22 1005Maybe you have known it before, ... -
Transaction Management Patterns In Brief
2010-02-09 10:27 1728There are several patte ... -
"扩展Spring的依赖注入行为"两例
2009-12-26 12:59 2687扩展Spring的依赖注入行为两例 ... -
框架API设计相关的碎言
2009-11-17 09:32 1548框架的API设计,应该是 ... -
自定义Mave archetype的创建
2009-10-29 20:12 12277Table of Contents ... -
看来有人已经有要抢先推出这个节目的意思了
2009-10-27 19:29 974这篇blog对java, clojure和scala中的并发处 ... -
Roma Documentation Outline
2009-10-27 17:35 150Roma Docume ... -
Hot Stuff - Lombok
2009-10-22 19:46 983give it a try, it's really cool ... -
ROMA框架潜在改进点思考(Thinking in ROMA improvements)
2009-10-21 19:53 1931. 关于ROMA现有表单 ... -
Valang Validator under the hood
2009-10-19 13:29 1616Table of Contents 1. Va ... -
ThreadSafety, Non-ThreadSafety 与 Stateless, Stateful有必然的对应关系吗?
2009-10-09 09:11 1819“It depends. ” 我们 ... -
A Big Piture On Concurrency
2009-09-12 09:49 11993- Concurrency Share (Concur ... -
尴尬的COC
2009-08-25 11:04 951Convention Over Configurati ...
相关推荐
Essential concepts of programming language design and implementation are explained and illustrated in the context of the object-oriented programming language (OOPL) paradigm. Written with the upper-...
Designing Event-Driven Systems_Concepts and Patterns for Streaming Services with Apache Kakfa, published by OReilly
Formalization and Verification of Event-driven Process chain
Data-driven Design of Fault Diagnosis and Fault-tolerant Control Systems 2014 杜伊斯堡埃森大学 丁教授
Event-driven application design
An Event-Driven Workflow Engine
With Implementing Domain-Driven Design, Vaughn has made an important contribution not only to the literature of the Domain-Driven Design community, but also to the literature of the broader enterprise...
用C语言实现的socket范例,包括了TCP,UDP协议,多线程socket已经event-driven socket
Event-Driven Programming: Introduction, Tutorial, History
Domain driven design distilled
a paper about saas in e-services
领域驱动,Domain-Driven Design (Tackling Complexity in the Heart of Software,资源来自互联网
Domain Driven Design is a very good book for exper
The software development community widely acknowledges that domain modeling is central to software design. Through domain modeling, software developers are able to express rich functionality and ...
Domain-Driven Design - Tackling Complexity in the Heart of Software
关于DDD可参考InfoQ的Mini Book Domain Driven Design Quickly , 还有 Banq 的文章 实战DDD(Domain-Driven Design领域驱动设计), 和 领域模型驱动设计(DDD)之模型提炼 。 本书分为四部分,第一部分讲述了领域模型...
Patterns, Principles And Practices Of Domain-driven Design
'Eric Evans has written a fantastic book on how you can make the design of your software match your mental model of the problem domain you are addressing. 'His book is very compatible with XP. It is ...