Open Heart

来源: BlogBus 原始链接: http://www.blogbus.com:80/blogbus/blog/index.php?blogid=2529 存档链接: https://web.archive.org/web/20050120170809id_/http://www.blogbus.com:80/blogbus/blog/index.php?blogid=2529

Open Heart Open Heart For Open World 关注JAVA和开放源码社区首页日记 (3) 技术 (4) 其他 (0) AOP (2) COP (3) 2005 年 1 月 Sun Mon Tue Wen Thu Fri Sat 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 最后更新已经搬家，重新开张 IoC Container Type 3 IOC 终于有别人也来看我的blog了 EclipseUml 一些AOP的基本知识单独建立一个AOP的分类究竟什么是Inversion of Control (or IoC for short)？如何构建框架？ TheServerSide Symposium 纯粹的技术座谈会最新评论 funpig : 呵呵，我还是时不. funpig : 呵呵，我还是时不. Mickey : 你好，请发一份ec. milk-illegal : <a href=http:. sdcsacsa : cascasc. jacky : 把你的eclipseuml. chenxihua : 你水平不错, 加油. chenxihua : 我的msn是chenxih. chenxihua : 你好, 手头有没有. eqiuno : 为什么要叫nannin. 存档 2003/07/07/-2003/08/19 我的链接 United Network Communications Corp. theserverside javablogs freeroller cnblog youcaisblog xiaolousblog 已经搬家，重新开张 -[日记] 不知道是不是还有人来访问，呵呵，很长时间没有更新过了，搬了个家，欢迎大家访问 http://www.feedhome.com/blog/page/pawa pawa 发表于 2004-12-17 15:44 阅读全文 | 评论(2) | 引用Trackback(0) | 编辑 IoC Container -[COP] 还真别说，我们还就是决定持久层用hibernate了，这样和gigix的方案一致了。关于IoC的使用，我能想到的是在表现层和持久层中间加入服务层，这个服务层全部被封装成为组件，使用container注册、管理、调用，在表现层决不有一行调用持久层的代码，全部放在服务层中，这样表现层可以选择各种不同的框架，我们有很多对Struts很熟悉的人，当时我也是设计了这样的架构，不过没有container的概念，要想实现诸如缓存、灵活控制事务、认证、支持多种表现层、支持多种持久层等就做不到。如果有了container，我想是不是可以把这些功能全部放在container中来进行，开发的服务组件只由商业逻辑，其它一概不管，全部由container完成。至于使用那个container，我还在看，有几个选择： PicoContainer 超轻量级，可以随便嵌入到哪里，不过需要自己完成很多代码，来实现我需要的功能，不知道时间是否允许。使用Tape 3 IoC，要用constructor注册，这个也遭到一些非议，这些没有真正使用过，只是感觉，觉得可以省去配置文件，省去设置context，自动找到dependency，不用实现和pico相关的任何接口，方便单元测试（直接new就行啦，不用烦人的mock，呵呵），更多的好处可能仍需观察中。简单是不是一定就是最好的呢？如果够用，我想应该是吧。 Spring Framework 次轻量级，这个框架就复杂些了，有从头到脚的DIY方案，提供了一个IoC的容器，有很好的和持久层继承的功能，特别对hibernate有参考实现了。他的文档也有比较详细地介绍，不过他采用的是Type 1 IOC，使用xml来注册管理组件，想一下tapestry就要那么多配置文件，就够烦了，还要再来，还没有工具，真是比较头大。他也比较了和Avalon、Pico的一些不同，我贴在下边，做个参考。 WebWork 这个还没有特别仔细看，他把容器部分好像也单独抽取出来形成了xWork框架，似乎完成和pico相似的功能，感觉上可能会考虑的周全些，使用了Type 2 IoC，我在以前的blog也介绍过一下这个东西。

附：String vs Avalon vs PicoContainer Spring Bean Container vs Avalon / Fortress Avalon is the oldest IoC container in the field, although still not very prevalent. It is basically just a set of interfaces for components and service managers, with various implementations. Most of the latter are in somewhat unclear states though, the only major ones are Phoenix and Fortress. For wiring up, every Avalon component needs to look up cooperating components via the Avalon ServiceManager, passed to it automatically if it implements the Serviceable interface. This is pretty intrusive, as practically every application component with dependencies has to implement that Avalon interface. Furthermore, the lookup mechanism is based on the service interface. If you want to receive a specific instance, you have to use the ServiceSelector with a specific key - another special mechanism. A difference in focus shows in that Avalon defines quite a lot of optional interfaces that a component can implement, like Startable, Stoppable, etc. Spring solely offers InitializingBean and DisposableBean as of 1.0 M1, mainly because there has not been demand for explicit start/stop cycles yet. Alternatively, one can also specify an "init-method" and/or "destroy-method" in the bean definition, so that a bean does not even have to implement a Spring-specific interface for such resource handling callbacks. Avalon's most important container implementation, Phoenix, targets standalone applications like full servers. Avalon has its advantages there, as it has been designed for start/stop cycles etc. The only stable implementation for embedded use like within a web application is Fortress, which competes with Spring's bean container. Spring focuses on embedded usage as application context, it does not aim to be a foundation for server processes. And of course, Spring's feature set for application development goes far beyond the bean container itself. Finally, an example of Avalon's programming model: If you'd like to create the above generic application context with Avalon, you'd have to subclass BasicDataSource and make it implement Configurable (for the parameters) and Stoppable (for the close call), or wrap it in a respective service adapter. Furthermore, "exampleDataAccessObject" would have to implement Serviceable to look up the DataSource, and use the ServiceSelector mechanism to choose one by some key if there were more than one. Spring Bean Container vs PicoContainer Another lightweight container getting attention recently is the PicoContainer. Its original incentive is to offer a more lightweight and less intrusive model than Avalon. It is built around components that specify dependencies via constructor arguments, instead of having to use some ServiceManager. This infrastructure intends to solve the same problems as Spring's application context concept but has some severe drawbacks: There's no notion of a specific component instance, just one implementation class for any given type. What if one would like to use 2 DataSource instances for 2 databases? How to configure the 2 differently? How to pass a specific one of those to a certain component? This is not possible with PicoContainer: It registers exactly one instance per type. Pico-managed classes are only allowed to have one single constructor, with all objects that the class depends on as arguments. This does not allow for convenient reuse of the class. Using existing classes is hard with PicoContainer: You have to subclass and write a single magic constructor there. Spring has the ability to work with any existing JavaBean. Inheritance is painful and error-prone when constructor chaining is required. Spring can use final bean properties to avoid errors. A constructor (or any method) with 10 arguments is a code smell and suggests refactoring into an initializer object. Spring can easily support this, via a bean reference. Unit tests concern one method of a service object. Why require providing all params to a constructor if you're really interested in the DataSource property etc? You only need to set the properties you require in Spring. JavaBeans are an elegant part of core Java: Why not use them? PicoContainer objects will need to follow a unique constructor pattern. JavaBean properties can be defined on interfaces if appropriate, or concealed if not. Why build constructors (an implementation issue) into an OO framework? Constructors are less obvious in IDEs than bean properties. It's trivial to see the properties on any object. In the future, Spring may offer dynamic reconfiguration of contexts, if beans can handle it by updating individual changed properties. With constructors alone this would mean changing the identity of the component. PicoContainer's main advantage is that it does not need instance-specific meta data like XML bean definitions, although it does need some kind of component and parameter registration. As this basic design strategy leads to the above mentioned severe limitations, we consider it questionable. Using very simple XML meta data, Spring offers a significantly more flexible and powerful infrastructure that achieves Pico's goals among other things. An example: To create the above generic application context with PicoContainer, you'd have to subclass BasicDataSource to give it one single constructor that takes all "necessary" parameters (is password or validationQuery necessary, for example?), and you would just be able to register one such instance for the DataSource interface (what if you'd like to access 2 databases?). P.S. on PicoContainer's new bean-style factory [24-07-2003] PicoContainer features a bean-style component factory now, as of 1.0 alpha-2, in response to the first version of this article. This can remedy some of the issues that we've mentioned, although PicoContainer still focuses on the constructor-based approach in all of its documentation. Note that the first and most important issue still applies: There is no notion of a specific instance for a given type. We consider passing a reference to a specific instance a very important feature for wiring up applications, which necessarily involves some kind of configuration like in an XML file (Spring makes this pluggable). PicoContainer sacrifices this to be able to adhere to its configuration-less "Type 3 IoC" dogma. Finally, regarding the argument that constructor-based "Type 3 IoC" cannot miss any dependencies: Why should every component need to receive instances for all possible dependencies and parameters? A bean-description-based approach, aka "Type 2 IoC" but without "enabler" interfaces, allows for optional dependencies without any hassle. We consider such flexibility more important than to avoid missing dependencies at any cost. pawa 发表于 2003-08-25 10:33 阅读全文 | 评论(3) | 引用Trackback(0) | 编辑 Type 3 IOC -[COP] 今天开始看IoC了，先主要看了PicoContainer的介绍，发现正是以前我想要得。用于MVC中的M层，提供服务组件，自己以前也有一个非常简陋的实现，但是基于继承的，感觉不太好用，虽然能减轻一定的编码工作，但是基本上没有什么重用性可言，因为持久层也是用了自己实现的一个简陋模型，需要在外部控制事务，我的这个服务层，基本上也就是作了控制事务的封装，本意是想实现能够组合组件可以任意开启事务，最大程度上服用这些服务组件，虽然能用，好像并没有达到效果。这个PicoContainer应该说能够解决问题了，gigix的分析很到位： “IOC也是个老词了，用它的另一个名字或许更容易理解――“好莱坞原则”：don't call us, we will call you. 也就是说，每个component是passive的，只有framework是active的，component的initialization和invocation都由framework管。” 具体讲到PicoContainer，号称是Type 3 IoC，怎么就变成Type3了呢？呵呵，让我的感觉是其实只是每个组件注册时候采用的方式不同，不过其他基本属性应该是一致的。下边摘录了一下他们三种的区别： Type 1 IoC (the Avalon way) forces components to be decode their own configuration metadata. Too intrusive. Type 2 IoC (the XDoclet way) looks cleaner: metadata is separated from code (albeit not from the source). But there's more to composition than property setting. Type 3 IoC looks like an attempt to disguise compositional metadata by placing it in the least imaginable place: the component's constructor! Again, there's more to composition than property setting. pawa 发表于 2003-08-18 16:13 阅读全文 | 评论(2) | 引用Trackback(0) | 编辑终于有别人也来看我的blog了 -[技术] 终于有别人也来看我的blog了只是自己水平有限，对不住大家：〉看了最近一期的程序员，才知道WebWork也是Richard Orberg的产品，看了他在freeroller上的blog，似乎很推崇IOC和AOP。他也提到了gigix提到的PicoContainer，这两天准备看看，正好我们要使用Tapestry作为表示层开发了，一定要找一个服务层和持久层的东西来支撑。 pawa 发表于 2003-08-15 13:39 阅读全文 | 评论(4) | 引用Trackback(0) | 编辑 EclipseUml -[技术] 好早就下载了 EclipseUml （一个功能强大的免费的不是open source的eclipse插件，可以画出各种Uml图，还能反向工程），不过一直没有用起来，昨天终于要用了……结果有点失望啊。功能确实很强，画出来的图也很好看，不过只有一点，也是致命的一点，速度太慢，不是一般的慢阿，如果开启了任何一个Uml图，整个eclipse就会狂慢，每次保存什么文件都要很长时间这段时间CPU占用率100%什么事情也做不了，太痛苦了。我想可能是因为EclipseUml类图需要实时跟java文件同步导致了这样的结果，找了半天也没有发现那里有设置不让他自动同步。看来软件如果光是功能好界面好还不行，最关键还要可用阿，想想编辑一个文件时间都花费在保存上，这还怎么用啊。想想自己以前做东西只管能实现什么都不管，真是汗颜…… 要做可用的软件 pawa 发表于 2003-07-25 11:19 阅读全文 | 评论(4) | 引用Trackback(0) | 编辑一些AOP的基本知识 -[AOP] AOP != Interception AOP isn't interception as in AOP is interception and more. This is my AOP manifesto, the least common denominator of all AOP systems (well, according to me at least): Interception As in "not being equal to AOP", also known as advice in the more academic AOP-world. It's basically the act of adding further processing to certain locations in a system. The locations are called points or join-points and an advice(interceptor) is typically applied to a set of points or a pointcut. I'm not convinced much more than method-interception is needed, but that's what is required at the very least. Introduction Do you remember your first lessons in object-oriented programming? The whole point was to modularize by encapsulating state and behaviour. So if interception is behaviour, introduction is state. Introduction should also make it possible to add further behaviour to an object, but in contrast to interception this behaviour is not interleaved with the existing code. Inspection This is somewhat a new area for the new wave of open-source AOP, but in some ways runtime attributes and method-names-patterns are in this are. While I don't believe field-interception is strictly necessary I do believe it's necessary to access information on what a methods does, what fields it modifies, what methods it calls, who calls this method, and so on... For example a object-relational framework could load fields from the database before the execution of a method that uses these fields. A transaction could be started if a method is called from the user-interface and if that method is modifying some external resource or persistent fields, directly or indirectly. Modularization Not only must it be possible to intercept, introduce and inspect, one must also be able to encapsulate it all in aspects. An aspect modularize the entire crosscutting concern (such as persistence, undo, transactions, locking, caching and so on) into one single module (possibly consisting of several sub-aspects, by delegation, inheritance or composition). This could be a Java-class or even... yuck XML. If you ain't got all of this, you ain't worthy being called 'AOP'. :-) 原文联接 http://freeroller.net/page/tirsen/20030618 pawa 发表于 2003-07-11 10:02 阅读全文 | 评论(0) | 引用Trackback(0) | 编辑单独建立一个AOP的分类 -[AOP] 只因为这个类别有点特殊哦现在JAVA开放源码社区，对这个东西很是热不过仍然属于比较前沿的领域我要给与更多的关注和学习 pawa 发表于 2003-07-11 10:00 阅读全文 | 评论(0) | 引用Trackback(0) | 编辑究竟什么是Inversion of Control (or IoC for short)？ -[COP] 不是一次看到这个词了，找到了一个实现IoC的框架xWork，有一点介绍，看了半天也不是非常明白，先收录下来，慢慢看。相关联接 http://wiki.opensymphony.com/space/XWork+Components Why IoC? So why is IoC useful? It means that you can develop components (generally services of some sort) in a top-down fashion, without the need to build a registry class that the client must then call to obtain the component instance. Traditionally when implementing services you are probably used to following steps similar to these: Write the component (eg an ExchangeRateService) Write the client class (eg an XWork action) Write a registry class that holds the component object (eg Registry) Write code that gives the component object to the registry (eg Registry.registerService(new MyExchangeRateService());) Use the registry to obtain the service from your client class (eg ExchangeRateService ers = Registry.getExchangeRateService();) Make calls to the component from the client class (eg String baseCurrencyCode = ers.getBaseCurrency();) Using IoC, the process is reduced to the following: Write the component class (eg an ExchangeRateService) Register the component class with XWork (eg componentManager.addEnabler(MyExchangeRateService, ExchangeRateAware);) Write the client class, making sure it implements the enabling interface (eg an XWork action that implements ExchangeRateAware) Access the component instance directly from your client action (eg String baseCurencyCode = ers.getBaseCurrency();) XWork takes care of passing components through to enabled action classes or other components. Some other benefits that IoC can provide include: A component describes itself. When you instantiate a component, you can easily determine what dependencies it requires without looking at the source or using trial and error. Dependencies can be discovered easily using reflection. This has many benefits ranging from diagram generation to runtime optimization (by determining in advance which components will be needed to fufill a request and preparing them asyncronously, for example). Avoids the super-uber-mega-factory pattern where all the components of the app are held together by a single class that is directly tied back to other domain specific classes, making it hard to 'just use that one class'. Adheres to Law of Demeter. Some people think this is silly, but in practise I've found it works much better. Each class is coupled to only what it actually uses (and it should never use too much) and no more. This encourages smaller responsibility specific classes which leads to cleaner design. Allows context to be isolated and explicitly passed around. ThreadLocals may be ok in a web-app, but they aren't well suited for high concurrency async applications (such as message driven applications). pawa 发表于 2003-07-10 14:59 阅读全文 | 评论(5) | 引用Trackback(0) | 编辑如何构建框架？ -[技术] 刚才看了Martin Folwer 的一篇文章，如何构建框架，感觉挺有意思。提出了两个概念 FoundationFramework 和 HarvestedFramework 。 FoundationFramework是说一开始就建造一个基础框架，然后在这个框架上边创建应用程序。看起来这个是很不错的。但是实际当中这样的实践却总是失败。因为一个框架最重要的是要保持他的API稳定，但是当一开始建造框架时不知道其他应用程序的需求，自然不能完整的保持它的API稳定，这样岂不是由了灾难性的后果。：（ HarvestedFramework这种就跟刚才那个不一样了，是一开始就建造应用程序，然后再用基本相同的构架建造第二个，抽取出代码有重复的地方，这样反复几次，一个好的框架就出来了。是不是感觉和这位大师的refactor理论很像呢？程序不是设计出来的是重构出来的：）原文连接，人家的标题就叫做Can you use refactoring to build a framework? http://martinfowler.com/bliki/FrameworkBuilding.html pawa 发表于 2003-07-10 13:39 阅读全文 | 评论(1) | 引用Trackback(0) | 编辑 TheServerSide Symposium 纯粹的技术座谈会 -[技术] 看了TheServerSide Symposium的介绍，果然不错，关注的全是JAVA社区最前沿的东西，下边有个内容列表，如果感兴趣可以直接去看原文 http://www.theserverside.com/resources/article.jsp?l=SymposiumCoverage Day 1 Bitter EJB: Common Programming Traps with EJB AOP, EJB and the Future of J2EE JBoss' AOP talk Transactions, Distributed Objects and J2EE Moden Driven Architecture and Productivity Analysis Casestudy Open Source Enterprise Development Panel Day 2 J2EE Myths and Why They're Dangerous Patterns Frameworks & Micro-Architectures Java.blogs: The movement, the site, the technology Rick Ross' keynote on Java Opportunity and Vision The Future of J2EE Panel Saturday Night Beer Tent Party Day 3 Introduction to Agile Modeling Next Generation of Applying J2EE Patterns Aspect Oriented Java Development pawa 发表于 2003-07-10 11:10 阅读全文 | 评论(0) | 引用Trackback(0) | 编辑 The Joy of Programming -[日记] 为什么喜欢编程？下边的一小段话也许能代表大部分的程序员心情：〉 Why is programming fun? What delights may its practitioner expect as his reward? First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake. Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office." Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate. Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both. Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be. Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men. pawa 发表于 2003-07-10 10:56 阅读全文 | 评论(0) | 引用Trackback(0) | 编辑今天开始新的旅程 -[日记] 前段时间的忙碌抉择，很多事情没有做，放下了很久的看书计划终于应该开始了，被公司安排了新的工作，有比较多的时间可以专心于一些技术的研究，还是感觉很舒服的，不用每天跟客户撤来撤去（也许我是在逃避？），呵呵，管它呢，反正现在这样我喜欢。上午弄了弄winamp，现在想听英文歌，顺便练习以下听力，就决定弄一个能显示歌词的玩意，找到一个MiniLyrics，可以显示歌词，还能自动从网上下载lrc的歌词，爽阿，省力气。不过我想听的一些歌他下不来，只好自己手找了，还好网上好人多，有不少，自从看过了8 mile似乎对rap有点感觉，看看能不能自己也说出那样的绕口英语（当然还可以学习骂人，好像很粗俗的样子，嘻嘻，娱乐为主，顺便学习一下英文）。今天开始要搞LDAP了，要好好看一下，有好的东西，再来这里做记录，呵呵。 pawa 发表于 2003-07-07 10:44 阅读全文 | 评论(0) | 引用Trackback(0) | 编辑分页: [1] 模板设计： Danger