Expert One-on-One J2EE Design and Development

​ j2ee的相关历史,spring的诞生背景,理念,重点章节。 4(Design and Standards)、9(data access)、11(Infrastructure)、12-13(web Tier)

有点乱,待整理思路

  • 4 Design Techniques and Coding
    Standards for J2EE Projects

  • 9 Practical Data Access

  • 11 Infrastructure and Application Implementation

  • 12 Web-Tier MVC Design

  • 13 Views in the Web Tier

Chapter 1

J2EE Architectures

Summary

  • 体系分层

    ​ EIS层 企业信息系统层 数据访问层? dao层

    ​ 中间层 业务对象 bizservice

    ​ 用户接口层UI层 web层

    ​ web 层

    ​ 模型 vo? Model-> json

    ​ 视图 html ui框架jsp 渲染引擎?->前端控制

    ​ 控制器 不应该有业务逻辑 负责转发 struct—>controller

    ​ 控制流程是一种 command的设计模式

    可移植性?

    通过使用一个抽象层(Abstraction layer),可以利用松耦合把该应用的奇遇部分与必须用一种平台特有方式来实现的任何部分隔离开。

    抽象层指一个其本身就独立于平台的接口。

    ​ spi的思想、 插拔式

Chapter 2

选择一个应用服务器标准

​ 得到支持的规范

​ sun资源 CTS ECPerf

​ 成本

​ 开发与部署

​ 启动速度 部署速度 内存需求

​ 额外步骤。编写部署描述符?

​ 热部署的能力

​ 服务器所提供的管理工具的完善度

​ SNMP(Simple Network Management Protocol)和JMX的管理标准集成度

​ 运行时候错误报告的质量

​ 文档质量

​ 可移植性的含义

​ 应用在应用服务器之间的可以移植性

​ 应用在服务器操作系统之间的可移植性

​ 更改J2EE应用所依赖的重要资源的能力 数据库切换?

​ 发布管理 指:保证一个应用发布从‘开发’ 、‘测试’到‘生产’到发展是可逆和可重复的

Chapter3

​ 单元测试的重要性

Chapter4 J2EE项目的实际技术与编程标准

​ J2EE应用的OO设计推荐标准

  • 利用接口来实现松耦合

  • 首选对象合成而非具体继承性

  • Template Method设计模式 将特定步骤留给子类实现

  • Strategy 将特定步骤抽成一个接口。在具体继承性和接口委托之间进行折衷的例子

  • 使用回调来实现可扩展 这是Strategy设计模式的一种特殊模式

​ jdbcTemplate

​ query(String sql,RowCallBackHandler callbackHandler)

​ public interface RowCallBackHandler{
​ void processRow(ResultSet rs) throws SQLException

​ }

  • Observer设计模式。实现关系分离

​ 例如处理登陆的对象为什么需要知道管理员的电子邮件地址、或者说如何发送邮件

​ 核心职责被淹没在特性中

​ publisher->events->Observer

  • 考虑合并方法参数 Command

  • 异常处理-已检查或未检查异常

​ 使用已检查异常会特有引起几个问题:

​ 太多代码

​ 难以读懂的代码

​ 异常的无止休封装

​ 一个异常相当于来自方法的一个可替代返回值的地方

​ 已检查异常要比错误返回码好得多

​ 如果调用代码能够对该异常做些切合实际的事情可以使用,否则使用未检查异常RuntimeException,选择是否捕捉,依赖应用服务器容器来捕捉.(而不是jvm)

​ 对异常进行详细描写

  • 使用反射 Factory

    误解

    ​ 使用反射的代码是慢的

    ​ 过分复杂

    ​ 如果使用得当,反射不会降低性能。正确使用反射实际哈桑应该改进代码可维护性。

    ​ 反射的直接使用应该仅局限于基础结构类。

  • 使用Java组件来实现灵活性

  • 使用应用组册表来实现单例 Singleton Prototype Factory

    ​ 支持接口

    ​ 普通javabean

    ​ 配置源上下文统一管理

    ​ 为什么不适用jndi ? 复杂 单一

编程规范

​ 一个方法只应有一项明确的责任,而且所有操作都应该在同一个抽象级别上

​ 避免代码重复

​ 避免字面常量

​ 可见度和作用范围尽可能小

​ 内部类和接口 避免空间污染

​ 使用final关键字

​ 开放式封闭原理:对扩展开放,对修改封闭。覆盖具体方法实际上是修改。

​ 和抽象方法联合使用,保护超类的完整性。

​ 使用界定符

实现一个框架

​ 向现有框架学习

​ 明确目标 、作用范围、 用最小复杂性来实现最大价值

​ Pareto Principle(2/8原则) 某个特定功能很难实现,问问自己是不是必不可少的,能不能实现其价值的大部分

Chapter 5-Chapter 9

Chpter 6

高速缓存,减少没必要的调用和消耗

DATA ACCESS

DB mysql自身

DB组件 hibernate缓存

应用层

​ 分布式缓存 redis

​ 单机jvm缓存 map guava cache

HTTP 304

Chapter 7

​ RDBMS 与 ODBMS

​ 范式化数据 消除数据冗余度

​ O/R 映射 尝试将Java对象的状态映射到RDMBMS上

​ 用于OLTP,不适用于OLAP

Chapter 8

​ 关于Session Beans 和 Entity Beans的讨论

​ 实体组件 分布式、共享的、事务性、持久性对象

​ Entity Bean 是一种糟糕的设计 ,不应该绑定在EJB容器上,应该交由专用的方案解决

​ 无法继承,不具备java对象

Chapter 9 实际数据存取

JDBCTemplete

​ 较高级的抽象 RDBMS建模为Java对象

==Chapter 11==

The Problem

​ Without such infrastructure, configuration management is usually haphazard. J2EE applications often hold configuration in a variety of formats, such as properties files, XML documents (an increasingly popular choice), EJB JAR and WAR development descriptors, and database tables.

​ 没有这样的基础设施,配置管理通常是随意的。 J2EE应用程序通常以各种格式进行配置,例如属性文件,XML文档(越来越流行的选择),EJB JAR和WAR开发描述符以及数据库表。

More seriously, application classes are bloated by configuration management code irrelevant to business responsibilities

应用程序类因与业务职责无关的配置管理代码而膨胀。

Equally harmfully, without a central infrastructure for configuration management, application code is to
likely to use variety to approaches to locating application objects. The Singleton design pattern is often
overused, resulting in problems we’ll discuss below. Alternatively, some application objects may be bound
to JNDI or attached to the global ServletContext (in web applications), both of which approaches
may complicate testing outside a JNDI server. Each application object is usually reconfigured
independently.

​ 通过各种方式去获取配置。每个应用程序对象通常都是独立重新配置的。

Using a Framework to Configure Application Components

外部化配置和OO设计

使用javaBean beanWapper

Using JavaBeans

​ If we make all application components JavaBeans, we maximize our ability to separate

configuration data from application code

​ However, manipulating beans is more complex, and requires the use of
reflection to instantiate objects and invoke methods by name. The core JavaBeans API does not provide
the ability to perform some useful operations on beans, such as

why ?

​ This provides the ability to manipulate beanseasily and adds the enhanced functionality described above, while respecting andavoiding duplicating the standard JavaBeans infrastructure.(andavoiding避免)

Using a “Bean Factory”

why?

​ The com.interface21.beans.factory package defines a way of obtaining beans by
name from a central configuration repository using a “bean factory”. ==The goal of a bean==
==factory is to remove any need for individual Java objects to read configuration properties==
==or instantiate objects. Instead, configuration is read by a central component, the bean==
==factory, and the bean properties exposed by each application object are set to reflect==
configuration data.== The factory then makes available instances of beans, each with a
unique name. Sophisticated object graphs can be created within the bean factory, as
managed beans may reference other beans within the same factory.

对外暴露BeanWapper

Application Context Goals

​ Building on the bean factory, an application context provides a namespace for the JavaBeans that compose an application or subsystem, and the ability to share working objects at run time. The com.interface21.context.ApplicationContext interface extends the ListableBeanFact interface, adding the ability to:

o Publish events using the Observer design pattern. As we discussed in Chapter 4, the Observer design pattern provides the ability to decouple application components and achieve clean separation of concerns.

o Participate in a hierarchy of application contexts. Application contexts can have parent contexts, allowing developers to choose the amount of configuration shared between subsystems.

o Share working objects between application components at run time.

o Look up messages by string name, allowing support for internationalization.

o Facilitate testing. With an application context, as well as a bean factory, it’s often possible to provide a test implementation that enables application code to be tested outside an application server.

o Provide consistent configuration management in different types of applications. Application contexts behave the same way in different kinds of applications, such as Swing GUI applications or web applications, and inside and outside a J2EE application server.

web层 (不是本周重点)

性能框架测试(不是本周重点)


转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 951488791@qq.com

文章标题:Expert One-on-One J2EE Design and Development

字数:2k

本文作者:zhengyumin

发布时间:2019-03-10, 19:45:18

最后更新:2022-08-04, 12:50:42

原始链接:http://zyumin.github.io/2019/03/10/Note_Expert-One-on-One-J2EE-Design-and-Development/

版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。