A: 充血模型中的Service Facade地位会有点尴尬 B: 讲什么东西啊？说清楚点！ A: 别急嘛，比如说 在Transaction Script模式下，表现层一般通过 类似于“XXXService” 的Facade来调用业务层的服务，是不是？ B: 是啊。不过在充血模型中，已经没有Transaction Script了，也就是说表现层就要直接通过调用Domain Object来获取服务了。 A: 对。 B: 这有什么不好？ A: 那还用说吗， 层和层之间的接口应该尽量单一和集中嘛，这样才能体现封装性嘛。 B: 哦，是。不过我们可以仍然保留一些很薄的Transaction Script作为Service Facade,这些Facade自己不实现业务逻辑，而只是给Domain Object做二传手。 A: 是。但 Facade一般怎么做二传呢？基本上都是在复制Domain Object的方法签名！，简直无聊死。 B: 这类Facade不要不行，要了又无聊，怪不得你说它们地位尴尬。
一篇文章只写一个小主题，这样才能让读者集中注意力。 不过此系列文章都是给自己看的，因为它们没什么新意，都是在别人牙慧的基础上总结出来的 =================================================================================== 结论： 充血模型比贫血模型更OO ========================================== A: 充血模型比贫血模型更OO.因为一个领域对象中既有数据又有行为，符合对象的定义 B: 这太牵强了！你还是说点有实际意义的吧。 A: 好吧。比如说，我们可以在充血模型中 通过多态消除IF/ELSE，这算是典型的OO吧。 B: 举个实际的例子吧。 A: 好。比如你还在上大学的时候，天天要去食堂。一般情况下，你还没开口，食堂师傅就给你打好了5毛钱的饭，为什么？ B: 因为我是男生。如果是女生，默认打3毛钱的饭。 A: 对。那请你用Transaction Script模式，也就是贫血模型，实现“默认打饭”逻辑。 B: void 打饭(student){ if(student 是 “男生”){ 打五毛； }else{ 打三毛； } } A: 好。看我这个 void 打饭(student){ 打(student.默认饭量()); } class MaleStudent extends Student(){ int 默认饭量(){ return “五毛”; } } class FemaleStudent extends Student(){ …
1. [Recommended]Web Application Stress (WAS) Tool( http://webtool.rte.microsoft.com/). 2. Apache JMeter (available at http://jakarta.apache.org/jmeter/index.html) 3.Grinder
也就是在当前所有的功能模块中做一下“切片”，切出来的片可以典型地代表系统的性能，如果这个切片能通过测试，那就可以认为系统性能可以满足要求。 那么怎么样决定哪个功能属于切片呢？"Often the vertical slice will implement some of the functionality that we suspect will have the worst performance in the application and some of the functionality that will be most heavily used in production"
我以前就是这样做的，自我感觉挺轻便，却被别人强烈鄙视，说是不合规范！ 现在你看，Rod Johnson自己都这么做，还有什么可说的？ 这样做还有个好处：“The advantages of expanded deployment in development are that it often enables individual files to be updated without full redeployment”
今天才知道，真土！
今天看到了Rod Johnson在他很久以前写的书上说， JXPath不错。 于是我去它的官方网站看了一下，确实很牛！看这一段就知道了！ ====================================================== Address address = (Address)JXPathContext.newContext(vendor). getValue(“locations[address/zipCode=’90210′]/address”); This XPath expression is equivalent to the following Java code: Address address = null; Collection locations = vendor.getLocations(); Iterator it = locations.iterator(); while (it.hasNext()){ Location location = (Location)it.next(); String zipCode = location.getAddress().getZipCode(); if (zipCode.equals(“90210”)){ address = location.getAddress(); break; } }
原文说： "Thus, to ensure correct replication behavior, always rebind a session attribute when the session data is changed." 比如，假设session中现有这样一个对象 session.setAtrribute("employee", employee); 现在改变一下这个对象的值 employee.setName("Changed Name"); 那么当前服务器节点上, session.getAtrribute("employee").getName() 就自动变成了"Changed Name". 但是Cluster上的其他节点呢？ 会不会自动更新？ 不同的应用服务器有不同的实现。为了避免不一致的情况，应该在改变employee的值之后重新调用一下 session.setAtrribute("employee", employee)，这样的话可以保证其它其他节点跟着一起更新，因为这是Servlet规范所规定的。
1. sqlException.getErrorCode() 2. sqlException.getSQLState() 3. sqlException.getNextException() 4. Remember to retrieve sqlWarnings from ResultSet/Statement/Conenciton
Expert One-on-One Oracle 中文版叫 Oracle专家高级编程