expert ont on one J2EE Development without EJB 笔记

expert one on one J2EE Development without EJB
作者:Rod Johnson
推荐书籍:《Expert One on One J2EE Design and Development》
    Martin Fowler《Patterns of Enterprise Application Architecture(企业应用架构模式)》
    四人帮的《设计模式》
    《Core J2EE Patterns(J2EE核心模式)》
   推荐网站:TheServerSide
        Artima.com
        Core J2EE Patterns网站
第一章:为什么"Without EJB",总结一句话，在不需要分布式支持的架构下，EJB出现过度设计的劣势
    分布式和RMI支持对于大部分J2EE应用是不必的，但开发者又必须为这些需求提供支持代码
    软件设计原则:
        简单
        【我们应该尽量降低架构的复杂度，只为现实的(和合理的可预见的)需求提供支持，不要试图预先把所有的问题都考虑进去，但是，在力求简单的同时，有必要多留意架构的设计质量，以保证未来能够对其重构，使其能够应对更加复杂的需求。对架构的重构不像重构代码那么简单，但既然我们不希望面对新的需求时被迫修改大量代码，就必须重视架构的重构】
        高产：EJB的弱点
        面向对象为本oo
        【oo的设计比具体的技术(例如J2EE)更加重要，我们应该尽量避免让技术上的选择(例如J2EE)妨碍
        我们使用真正的oo设计】
        【一旦你发现自己正在编写一个“不是真正对象”，也就是说，只有一些用于暴露数据的方法的对象,你就应该
        想想自己为什么要这样做，是否有更好的选择】
        业务需求至上：EJB有太多不且实际的需求
        重视经验过程:循征
        【不仅不要相信这些技术架构，也不要相信我们或者别的任何人，请为你的应用搭建一个垂直切片，根据
        你的关键需求去考察它，“问问电脑”那个架构最适合你的的需求】
        重视可测试性:"测试先行开发"等敏捷开发要求代码测试案例，J2EE没法测试
    EJB的价值:8/2法则表明，花20%的力气就可以解决大部分80%的问题，而要解决剩下的少部分问题则需要多得多的问题，
        这个法则告诉我们:架构的价值在于为常见的问题找到好的解决方案，而不是一心想要解决更复杂也更罕见的
        问题
第二章:目标
    1.生产率，当然也包括可维护，可靠，可伸索
    提升生产率更好的方法：
        1.架构(避免不必要的架构复杂性，使用抽象层将J2EE或J2SE核心API的复杂性隐藏起来，
            尽量使用O/R工具简化持久层，使用一个好的应用框架)
            A.架构问题【如果项目真的非常复杂。代码生成会是一种有用的做法；但一般来说，与其借组代码生成来应付，不如想办法降低复杂
            度。更好的办法包括:采用尽可能简单的设计方案，使用合适的框架避免重复代码等。不要奢望用代码生成来完成复杂的架构】
            内部解决方案与开源方案的劣势:浪费时间-应该专注于应用域问题
                        困难-好的基础设施必须经过2-3的迭代磨砺，麻烦
                        不标准-自主开发没有标准，学习成本高，新人难上手
                        通常没有合适的开发文档
            B.【永远不要开发自己的基础框架来解决资源管理或者日志记录之类的“标准问题”，只有自己独有的需求，才值得自己动手
            解决，在写下任何一行代码之前，你应该仔细分析，确定那些问题可以求组于开源方案，那些问题确实需要自己解决，
            J2EE社区有大批量的开源方案，可以解决大量的常见需求】
        2.专注，以及方法学(弄清自己要解决什么问题，专心把这个问题解决好，
                选择一个合适的参考架构，从一个模板应用开始，
                使用敏捷的开发过程)
        3.适用合适的工具：eclipse Profiler
    
            
    2.面对对象oo:避免传输对象DTO
        【除非别无选择，不要容忍“伪对象”的存在】
    3.业务需求的重要性：不要关系技术需求，专注于业务领域需求
    4.经验过程的重要性：“循征软件架构”
            【一定要在项目初期就开发一个垂直切片来验证应用的架构，不要相信任何人的建议，除非自己证明过，这确实符合需求】
第三章：各种架构
    1.架构组成：业务服务层、表现层、数据访问层
    业务服务层：完备、简单、以接口的形式而不是类的形式定义、面向对象独立于表现层和数据访问层、事物管理、便于测试
        【尽可能使用无状态服务层设计应用系统，尽可能把状态保存在web层而不是业务逻辑层】
        【不要在web层中实现业务逻辑，业务逻辑应该独立于表现层】
        【Web层应该很薄，应该搭建在服务层上面，其代码只是用来解释用户的操作，显示响应的结果】
    数据访问层：对持久化数据的访问效率往往决定了企业应用系统的整体性能
        如果采用SQL JDBC方式而不是O/R工具访问数据库，应该通过一个完善的抽象层间接调用JDBC
        J2EE模式中的“数据访问对象”就是一种混合多种策略的正确途径。它用一个DAO接口隐藏持久化操作的细节，这样使用这个模式的
        业务对象就无需知道底层的持久化技术知识(jdbc api)
    petStore实例分析:【不应该接到异常后立刻抛开。遇到无法恢复的异常，不应该把它当成受控异常扩散下去，这样容易让人养成不好的习惯，
    应该受控异常包装成非受控异常，或者用一个框架替你包装异常，如果滥用受控异常，那么非受控异常就没有意义了】
第四章：简单的重要性
    幻影需求:【任何与业务逻辑无关的代码都需要注意和反思】
    【如果你在乎简单性的话，就应该避免编写分布式的应用系统】
    【要想获得具有高扩展性的应用系统，最好的办法是构建一个高效的应用系统，这样才能尽可能地利用单位硬件的吞吐能力，也就尽可能地
        减少对横向扩展性的需求，而并置应用系统天生就比分布式应用系统更加高效】
    【总体来说，工具上的复杂性是危险的，选择最简单的工具，就尽可能地选择简单架构一样，能带来真正的价值】
    开发工具:【在选择开发工具和开发过程的时候，应该着重考虑“选择能够奏效的最简单的做法”。在很多方面，一些成功的开源项目是一种好的范例，
    它们通常使用非常简单的工具，这样尽可能地减少工具对开发者的妨碍，依靠优秀的开发实践，往往要比信任那些由工具强加的开发过程要好】
    开发者:【优秀的开发者都对智力上的事情具备好奇心，为自己会使用的技术感到兴致勃勃，但是，只有最出色的开发者，才懂得克制以上的冲动，
        服务于真实项目的需要(尽可能用最简单的技术处理复杂的业务)】
    架构师:【对于软件的“架构”而言，实现架构往往会遇到各种的问题，而解决这些问题则需要具体，详尽的细节知识，只有掌握了所有这些细节
        知识，才能确定整个系统架构，所以，如果架构师把时间都花在编写文档、搭建模型上，那也很难作出切实可用的架构】
        架构师必须参与一定的编码工作
    架构是“简单”好还是“复杂”好?【一个架构可达到的复杂程度，应该取决于业务需求，而不是技术。理想情况下，架构满足业务需求的能力可以
        根据经验方法评测出来，而不是凭意断】
        切忌过分推断需求。别去实现那种两年后才能用上的潜在需求。那些需求可能永远也用不上，即使真正出现这样的需求，其形势也
        可能不同于你的推断。两年后，你也不一定还在这个项目上。
    架构刚刚够好就行吗?维护软件才是最花钱的地方！
        【不要停留在那种刚刚能用的东西上，开发者的目标，应该是作出满足需求的最简单方案，并且用最少的代价开发出来，维护下去】
        开发软件有2个方法：一种是尽量把事情做得简单，让人一看就知道系统明显没有缺陷；另一种则是把事情尽量做得复杂，这样
        一来，也就没有了明显的缺陷
第五章：EJB的五年
    CGLJB-hibernate技术
    【设计EJB线程池的主要动机是要避免垃圾收集和节省内存，如今的JVM收集垃圾的效率高许多，而且内存也便宜很多，就是说，
    这2个动机不重要了】
    标准
        【很多时候，标准是有力于行业的；但是有些时候，它们抑制类创新；还有些时候，它们把糟糕的技术立为标准，
        开发人员应该根据实际的需求来选择技术方案，而不是盲目轻醒标准】
    “法律标准”和“事实标准”的差别在于“法律标准”是标准制定者凭空发明的标准
    最好的标准化是对业界已成熟的领域的标准化，这些已经成熟的领域经过事实的发展探索，已经具备成功并且成熟的解决方案，对没有充分理解
    的领域标准化很难找到事实的依据
    J2EE世界最好的优点就是开源方案很多并且很优秀，普遍质量较高，但是一个项目中也不能使用太多的开源方案。
    开源产品的选择:1.尽量减少使用产品和技术的数量，太多会使你的总体技术组合变得复杂，应该选定一种熟悉有价值的方案，并一如既往的使用下去
        2.不要随便组合开源产品，除非已有这样的常见组合,没有好的理由，不要做开路先锋
        3.不要轻易升级开源产品，不要让开源产品牵着你的鼻子走
        4.使用具备文档的框架
        5.最好的框架应该尽量减少应用代码对框架的依赖，避免产品锁定
        6.不要以为开源就需要成本
第六章：轻量级容器和控制反转
    1.容器的责任:生命周期管理、查找服务、配置管理、依赖决议
    2.增值服务:企业级服务(事物管理)、线程管理、对象池、集群服务、管理容器、远程服务、暴露远程服务、消费远程服务、定制扩展
    3.特性:可管理应用代码，但不给代码强加容器依赖(非侵入)、可快速启动、部署简单、纯Java实现无其他API依赖
    Ioc实现策略：【依赖注入的基本原则是：应用对象不应该负责查找资源或者其他依赖的协作组件，配置对象的工作应该由Ioc容器完成，
    “查找资源”的逻辑应该从应用代码中抽出来，交给容器负责】
    【依赖注入可以尽量减少应用代码对容器的依赖】1.代码尽量避免对容器的依赖(少用容器API)，
        2.如果必须使用容器某些服务，使用申明式而非编程性使用
第七章：spring简介
    spring项目出发点:解决其他框架忽略的部分、易于选择、易于使用、鼓励最佳实践但不强求、非侵入式、统一配置、易于测试、可扩展
第八章：基于AOP概念的声明性中间件
    1.衡量OOP成功与否的标准就是它在多大程度上避免了代码重复
    【代码重复是最糟糕的代码臭味，只要出现重复的代码，必定有什么地方存在验证问题-要么设计有问题，要么实现有问题】
    【AOP应该被看作是OOP的补充，而不是竞争对手，AOP可以弥补OOP的一些缺陷】