AndroMDA Getting started(一)

AndroMDA Getting started(一) 

AndroMDA Getting started

1．Getting started with AndroMDA

理解新工具和技术是一件令人畏缩的任务，AndroMDA也不例外。这篇教程作为AndroMDA的能力的温和的介绍。我们将想你展示如何一步一步的设置你的开发环境和构建你的第一个java应用。我们将关注思想和概念而不是机械的一系列的步骤。用这些知识武装你来准备应对真实世界的挑战。请花费半天不受打断的时间来学习AndroMDA。

 

2．Application Architecture

现代企业应用使用一系列的组件，来连接其他的每个提供特殊功能性。执行相似功能类型的组件通常分在层中。这些层更多的为高层使用提供服务。在给出层的组件一般使用自己层中的其他组件的功能或底层的。下面的图显示一种企业应用流行的层次结构。

 

表现层：表现层包含需要和应用的使用者交互的组件。例如web页面，rich client表单，用户交互处理组件等。

业务层：业务层封装了应用业务功能的核心。简单的业务功能能使用无状态的组件然而复杂的长期运行的事务能使用有状态的工作流实现。业务组件一般被作为隐藏复杂的业务逻辑的façade服务接口的前端。太合适一般我们所知道的SOA。

数据访问层：数据访问层提供了一种简单的访问和操作数据的的API。这一层抽象底层数据访问技术，因而允许业务层重点放在业务逻辑。每个组件典型的提供了create，read，update，和delete（CRUD）操作给特定的业务实体。

数据存储层：企业应用保存他们的数据在一个或多个数据存储中。数据库和文件系统是两种非常常用的数据存储。

 

层是简单的构成应用的组件的逻辑组织。这些被部署在物理机器上的层如何依赖于一系列的因素来改变。在非常简化的场景中，所有的层能位于一个机器上。在稍微更复杂的场景，表现层能位于一个机器上，业务和数据访问层在第二个机器上并且数据库在第三个机器上。更精确的常见是可能的。例如，一个高吞吐量的web站点可能部署表现层在一个十台机器组成的web环境中。

 

3． Architecture of AndroMDA Generated Applications

我们了解了隐藏在现代企业应用后面的基本概念，让我们讨论如何应用AndroMDA实现这些概念。AndroMDA把UML模型作为他的输入业务模型并且生成需要构建java应用的重要部分。AndroMDA有能力自动把高级的业务描述翻译成生产质量的代码，来减少实现java应用的时间。下面的图反映了不同的应用层的java技术支持。

表现层：AndroMDA当前提供两种技术来构建web基础的应用层：struts和JSF。接受UML活动图作为输入来描述页面流和生成适合Struts或JSF框架的web组件。

业务层：业务层被由AndroMDA主要组成的服务来生成，使用Spring框架来配置。AndroMDA在业务逻辑能被增加的实现类中创建空的方法。生成的服务能选择成为带EJB的前端。在这个场景中，服务必须被部署在一个EJB容器中，例如JBOSS。服务也能被暴露成web service，提供一种客户端访问他们功能的平台无关的方法。AndroMDA能为jBPM引擎生成业务过程和工作流。

数据访问层：AndroMDA以流行的ORM工具Hibernate作为依靠来生成数据访问层。它为实体生成UML模型中定义的DAO。这些数据访问对象使用Hibernate API来把数据库记录转换为对象。

数据存储：因为AndroMDA使用Hibernate来生成对数据的访问，你可以使用Hibernate支持的任何数据库。

 

4．层之间的数据传递

在上面讨论的概念，理解数据如何在应用的不同的层之间传递是非常重要的。让我们自底向上开始。

 

正如你所知，关系数据库存储数据作为表中的记录。数据访问层从数据库中读取这些记录并且把他们转换成在业务领域中表现为为实体的对象。因此这些对象叫做业务实体。

 

数据访问层通过业务实体到使用这些实体来执行业务逻辑的业务层。

 

最后要讨论的是在业务层和表现层之间传递数据。一些人建议表现层应该直接访问业务实体，另外一些人正相反，业务实体应该被表现层所限制并且业务层应该封装必要的信息到一个名为“value object”的对象并且传输这些对象到表现层。让我们来看看这两种方法的优缺点。

l        业务逻辑不在包含在业务层。在表现层能自由的操作实体是非常有诱惑性的因而扩展了业务逻辑在很多地方－显然是一场维护的噩梦。在这种情况中有多个前端到服务，业务逻辑必须在所有的这些前端重复。另外，没有一种应对表现层影响实体的保护性措施－故意的或者无意的。

l        当表现层运行在多个不同的机器上时（在一种rich client的情况中），序列化整个实体和通过线路发送实体是非常低效的。考虑一个显示订单列表给用户的例子，在这个场景中不应该传输每个订单的订单明细到客户端饮用。所有你需要的或许只是订单编号，订单日期和每个订单的总数，如果以后用户希望看到指定订单的明细，你可以再序列化订单实体再通过线路发送给他。

l        传输真实实体到客户端可能出现安全风险。你希望客户端应用能访问到在雇员对象内部的工资信息吗？或者在订单对象中的边际利润？

 

Value object提供了所有这些问题的解决办法。的确，他们需要你写一点额外的代码，但是作为回报你得到了一个和表现层有效通讯的业务层。你可以像被控制的视图一样考虑value object。AndroMDA提供了一些在实体和value object之间的基本的事务支持，你会在教程中看到。

5．服务和Hibernate会话

      关于AndroMDA生成应用的另外一个关键概念是在服务方法之间的强关联和Hibernate session。但是在我们介绍这个概念前，我们必须准备一些背景工作。Hibernate session是一种运行期对象，允许应用create，read，update和delete在数据存储中的实体。当session是“open”，这些实体被访问到session并且你可以使用他们之间的管理从一个实体浏览另外一个。如果相关的实体不在内存中，则Hibernate自动把他获取给你（这叫做“lazy loading”）。然而，你一关闭Hibernate session，在内存中存在的实体被认为是“detached”，Hiebernate不在知道他们了。如果你偶然视图访问这样的关联实体，你会得到Hibernate的LazyInitializationException。

 

现在我们了解了背景，让我们讨论在服务方法和Hibernate session之间的关系。当客户端应用调用服务方法时，一个新的Hibernate session自动打开。你无需写任何代码做这些事。同样的，当服务方法推出时，关联的Hibernate session会自动关闭。也就是说，Hibernate session的生命周期与服务方法的调用的开始和结束绑定的。因此，被访问到Hibernate session中的实体在服务调用期间持续，在服务调用结束消失。所以，如果你的服务方法反悔裸实体，客户端必须额外小心不要访问已经不在内存中的相关的实体。总之，你可以避免这种情况，通过在更早章节的建议，例如，传输所有的相关信息到value object。另外，考虑服务方法作为逻辑事务边界－在这个方法中作任何你需要的事情并且返回value object作为结果。

 

在服务方法和Hibernate session强关联之间的另外一层隐喻是客户端应用不要试图越过服务层和底层直接交互。你可能很讨厌强制使用data access object的方法，但是很快或不久你就会发现陷入了麻烦。