企业应用通盘考虑

关于架构：

  最高层次的系统分解

  系统中不易改变的决定

  管道方式

  过滤器方式

  分层，如何将企业应用组织成不同的层次，以及这些层次之间如何协同工作。

  根据应用的复杂程度来分层，应对不同的分离方式，有一条关于依赖性的普遍原则：领域层和数据源层绝对不要依赖表现层，这条原则将简化在相同的基础上替换表现层的待嫁，也使得表现层的修改所带来的连锁反应尽可能小，领域层与数据源层的关系更为复杂，其取决于数据源层的架构模式。

 

 关于性能：

   尽量减少远程调用

     响应时间：系统完成一次外部请求处理所需的时间。

     吞吐率：单位时间系统处理多大的请求量。对于企业应用来说，吞吐率是每秒事务数（tps）来度量。

     响应性：系统响应请求的速度有多快。为了提高响应性可以损失一些响应时间和吞吐率是值得的。

 

模式

   每一个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。

   你什么时候能不用她？

从领域层说开起

    如何建模，如何抽象领域模型就变得很难，因为 如何使用领域模型是很难学习的，另外领域模型的数据库连接非常复杂。

 

数据源层

  对象与数据库，如何映射？

    活动记录

    实现松耦合：使用表数据入口或行数据入口

    随复杂度的进一步增加：考虑使用O/R映射 确保领域模型尽可能与其他各层相互独立。

    存储过程看做一个性能优化的步骤，而不是看做一项架构原则

   持久化数据？

  很多人同时访问数据？确保两个人在同时操作同一数据项时不出现错误，事务管理可以处理这个问题。但无法做到对应用开发者透明。

 

表现层：

  胖客户用户界面     需要对客户程序进行控制和部署管理

  HTML浏览器界面   尽可能使用这种方式

     Martin 建议使用模型—视图—控制器作为设计基础

     站点面向文档：推荐使用页面控制器 特别是当既有静态页面又有动态页面的时候。

     如果站点导航机制和UI更为复杂，考虑使用前端控制器

  关于视图

     主要有两种选择：模板视图和转化视图，

     如果开发的是一个有多种表现形式的站点，考虑使用两步试图

 

与下层通信：

   尽可能将所有的东西运行在一个进程中，这样就不用考虑低效的进程间通信

   如果无法再一个进程中完成，可以将领域逻辑层用远程外观包装，然后使用数据传输对象实现与Web服务器的通信。

   Web Services是应用集成而不是应用架构的技术。