英语原文共 22 页，剩余内容已隐藏，支付完成后下载完整资料
基于MVC架构的电子商务应用设计和实现
E. Althammer and W. Pree
C. Doppler Lab for Software Research
University of Constance
Campus P.O. Box D188
D-78457 Constance, Germany
althammer@acm.org, pree@acm.org
摘要
虽然模型与视觉表示（视图）的分离意味着众所周知的好处，但可用的Java库不足以支持这一概念。本文提供了一种直观的方法，可以独立于特定的图形用户界面（GUI）库，在此方向上平滑地增强Java库。灵活的框架JGadgets，受到Oberon Gadgets系统的启发[1]，允许开发者专注于模型编程。 这显着降低了开发成本，特别是在商业电子商务系统中普遍存在的相当简单的基于表单的GUI领域。
我们首先提出了一个在JGadgets上实施的小案例研究，展示了MVC架构的优势。 然后，本文将对JGadgets本身的基于反射的设计进行素描。
关键词：软件组件，重用，MVC架构，反思，自动配置，Java
1介绍
许多商业应用，特别是电子商务应用，都有一个客户端服务器架构，大致遵循图1中的示意图。 1：客户端访问和操作存储在服务器上的数据存储库中的数据。 客户端可能在概念上分为模型和视图组件，其中模型对应于特定的客户端业务逻辑和视图到模型的可视化表示。 服务器由包含服务器端模型的应用服务器和包含数据库的数据存储库组成。 本文重点介绍了客户端的模型视图，并省略了服务器部分。
现实世界商业客户端/服务器系统中的客户通常由几十个数组组成，如果不是整个应用程序的数百个对话框。除了仔细的数据建模外，开发和增强这些应用程序还涉及到执行对话框的繁琐任务，以便最终用户可以查看，输入和编辑数据。 由于图形用户界面（GUI）变得流行，许多工具支持“绘制”这些对话框，并以各种方式自动开发客户端部分。
我们发现Java 2的最先进的Java开发环境（以前称为JDK 1.2）[2,3]仅部分自动化这些应用程序的客户端部分的开发。 虽然这些工具让开发人员绘制GUI并生成一些事件处理代码，但并不追求模型及其视图的明确分离。
当客户端服务器应用程序必须为具有不同特性的不同客户端服务时，模型视图分离至关重要。 桌面客户端具有大屏幕和强大的处理器，而PDA（诸如PalmPilot的个人数字助理）或者移动电话的屏幕相当小。 由于应用程序必须适合于不同的客户端（取决于设备的特性和功能），因此通常需要实现和维护每个设备的客户端应用程序的单独版本。
通过将视图与模型分开，我们可以通过仅使用一个版本的模型来保存开发和维护费用（因为每个客户端类型的模型是相同的）和每个设备的自己的视图版本。进一步思考，可以从模型描述中自动生成视图，以使开发成本最小化。
因此，支持模型视图分离的框架应该建立一个单一的模型为不同的意见。对于开发人员来说，这意味着他或她只是专注于使用模型，框架会从模型描述中生成视图。
视图下的GUI库取决于所使用的平台以及JVM的类型（java虚拟机）。例如，桌面客户端（使用Java 2标准版）可能依赖于Swing或AWT，并且PDA客户端（使用Java 2微型版本）可能依赖于KVM GUI库[4]。这些库是不兼容的在彼此之间，不能轻易交换。为了允许平台的切换，框架应该封装不同的GUI库。总体上，模型视图分离应该为开发人员带来以下好处：
简化开发。开发人员几乎可以忽略GUI表示。 与bare-bone Swing编程相比，事件处理也应该简化。
应该支持不同的平台。平台的切换以及使用的GUI库不应影响已经开发的对话框或模型。
更好地重用组件。开发人员应该能够独立于其视觉表示来定义和重用模型组件。
模型视图分离应该支持如上所述的客户端 - 服务器的开发人员。 同时它应该尽可能少的间接费用。 这些考虑之后的增强功能被实现为一个称为JGadgets的小框架。 类似于Oberon Gadgets系统，基于Java的模型视图框架JGadgets应该基本上处理功能，如同步模型和视图以及自动化事件处理。
JGadgets是由奥地利Raiffeisen银行集团的软件公司和康斯坦茨大学软件研究实验室的RACON Linz Software GmbH（简称RACON）合作开发的RACON将Java技术与JGadgets一起应用于各种系统的客户端部分，特别是桌面PC和手机的网上银行应用程序。
JGadgets来源于[5,6]中描述的原始MVC（模型 - 视图 - 控制器）架构，但在几个方面有所不同。 以下小节评估传统MVC架构的最重要特征，并将其与JGadgets架构进行对比。
1.1 JGadgets与传统的MVC架构
MVC假定一个模型不知道哪个视图被插入它。因此，它允许在同一模型上的多个视图和解耦变化观点。 JGadgets采用不同的方式：模型知道它的存在视图和视图的组织方式（即视图层次结构）。动机在这之后，模型通常不是设计而不考虑如何视图看起来就像。另一方面，解耦比甚至更强MVC。模型和视图不必知道对方的界面。连接是根据命名约定动态完成。这种方法允许更灵活模型和视图的连接。
MVC架构提供了严格的视图和控制器分离。然而，这可能会给系统带来额外的复杂性。控制器不能完全脱离视图，因为它们必须了解触发的事件视图。因此，每个视图需要其特殊控制器。这个想法是放弃严格的MVC将视图和控制器集成到单个组件中。现代GUI诸如基于MVC架构的Swing等库这样做。例如，Swing列表有两个类，即对应于视图和控制器的JList和对应于模型的ListModel。 Swing为大多数组件提供了模型视图分离。 JGadgets不会组合视图和控制器，但是提供控制器的一般实现，作为框架的一部分自动化基本的MVC操作，如事件传播，连接，模型和视图的同步和断开。
MVC架构通常会降低性能。每个更新的模型导致视图的更新，并且用户事件导致控制器联系模型。当模型和视图通过网络分布时，这是至关重要的。如同基于Web的客户端服务器应用程序因此，必须引入模型视图交互一个最小值，分别一部分模型必须保存在客户端，如图所示1。
MVC架构基于只有一个模型的存在，而不是指定应用程序中应该如何组织不同的模型。 JGadgets通过引入一个控制器层次结构来扩展MVC范例模型和它们之间的相互作用。
MVC可以独立于其可视化表示来促进模型组件的透明重用：典型的模型元素是具有用于添加，修改和删除列表项的关联按钮的列表框以及用于编辑它们的编辑器对话框[8]。列表框（列表处理，按钮）非常简单，因此可以轻松重用。但是，列表框的视图可能会有很大的不同：列表视图可以是单列或多列列表或组合框;按钮可以对齐或底部对齐。一个按钮可能被遗忘或存在两次，依此类推。通过分离模型和查看开发人员可以重用（黑盒）模型组件，但不限于使用某个视图模板。类似地，可以定义视图和控制器组件。由于JGadgets的模型层次结构，模型组件的重用性变得更加简单。
总之，JGadget的重要方面是模型和视图之间的自动链接机制，通用控制器和这些组件的可扩展性。
下一节介绍JGadget从开发人员角度来看的功能和用途。第3节介绍了框架的核心设计方面的讨论。我们假设读者熟悉[9,10,11]中描述的面向对象框架的核心概念。
2通过模型分析减少发展努力 - 案例研究
示范对话框（见图2）显示了真实的德国标签，允许最终用户检索有关银行客户的信息。 选项卡控件支持选择各种搜索条件，如姓名，个人识别号码，账号和电话号码。 在基于姓名的搜索的情况下，最终用户输入姓氏（名称/Bezeichnung）的文本字段和/或名字（标记为Vorname的文本字段）和/或公司开始的出生日期或日期 其操作（文本字段标记为Geb./Gruuml;n.Dat。）。 按下搜索（Suchen）按钮后，对话框下半部分的列表显示搜索结果，在此搜索范例中客户名称为施瓦辛格。
为了显示或修改与列表中选择的客户相关联的详细信息，最终用户按下Modify（Auml;ndern）按钮。 这将打开另一个可以编辑相应数据的对话框（参见图3）。
图中所示的视图 2和3是相当复杂的，并且经常被改变。如果应用被移植到具有小显示器（例如Palm Pilot）的设备，则视图必须被分成几个单独的视图。 模型视图分离使得该过程显着更容易。
下一小节描述了开发人员通过图1的案例研究来组合一个具有JGadget的应用程序。 2和3。
2.1概述
开发人员仅实现应用程序的模型部分。 视图是从模型描述生成的，并使用GUI编辑器进行编辑。 控制器是框架的一部分。 因此，以下小节的主要部分专用于模型编程。 视图部分描述了视图生成，并且控制器部分描述了模型编程器使用的控制器API。
2.2 JGadgets中的模型编程
定义模型的开发人员基本上定义了我们称之为属性和服务的属性.Attributes存储与JavA中的任何对象类型对应的特定类型的数据。这可以从基本的Java类型（例如Integer，Float，Double和String）到 更复杂的结构，如列表或格式化字段（日期字段，货币字段等）。
服务是不包含数据但是描述业务逻辑的自包含操作的模型实体。 业务的输入和输出参数存储在属性中。 例如，服务搜索客户机使用搜索条件执行数据库上的客户数据搜索。 搜索条件在一组String属性中指定，结果（与条件匹配的客户数据）存储在列表属性中.Attributes和服务成为表示模型的类的实例变量。
2.3属性和服务
JGadgets要求开发人员将数据专门存储在属性中，以保持其与视图同步。 模型开发人员必须了解属性和服务的API，因为它们代表每个模型的框架。 这就是为什么我们从属性和服务的属性和方法开始.JGadget的其他功能，如事件处理，依赖于这些概念。
2.3.1属性的实现
JGadgets提供类JGAttribute作为属性的一般抽象（注意属于JGadgets的类都是从JG开始的...）。 JGAttribute实现为Java bean，并具有一组属性，如表1所列。
请注意，某些属性是绑定的，这意味着JGadgets会自动通知并在该属性更改时更新相应的视图元素。属性标有*。标有**的属性是只读的。它们由JGadgets自动设置。属性可以分为三个类别，即数据字段，MVC字段和可访问性领域。
数据字段管理属性中包含的数据。 data属性成立实际数据。请注意，JGadgets中不允许使用原始类型。相反，包装使用诸如Integer的类。 type属性（类型）指定哪些数据类型可以存储在属性中。无论何时尝试更改数据属性，执行类型检查：仅数据是指定类型的实例（因此也是子类型）或包含兼容的字符串表示的字符串数据类型被接受;不兼容的数据被拒绝。例如，整数属性只接受整数或包含整数值的字符串。属性dataOld保留备份数据。
请注意，“正常”Java编程的唯一区别是单个实例变量被包装到JGAttribute对象中。 JGAttribute本身是永远不会的子类，属性的变化在type属性中实现是任何有效的java类。因此，可以使用所有现有的Java类。数据被访问与JGAttribute的方法getData（）。由于此方法返回类型的对象对象，结果必须被转换为正确的类型。必须使用数据的setter方法setData（）来实现数据更改才能启动JGadgets更新机制。对于复杂的数据更改，建议您制作数据的本地副本，在副本上执行更改并仅调用setData（）一次。
MVC字段负责维护模型，视图和控制器之间的关系。 每个属性都有一个对控件对象（控制器属性）和对应的视图小工具（views属性）的引用。 这些属性由JGadgets自动设置，为只读。
可访问性字段描述了属性的封装数据的可访问性状态。 诸如启用，可见和焦点的信息以某种方式引入了模型中的视图风格。 因此，模型元素包含视图信息的事实似乎破坏了严格的模型/视图分离。 我们认为这些信息属于业务逻辑，因此属于模型。 业务逻辑指定属性的实际状态，例如，如果它是可访问的。 这由属性的标志启用表示。 JGadget注意到视图正确显示状态。这迫使开发人员更仔细地描述业务逻辑。 将这些属性放入模型的第二个原因是保持多个视图同步。
属性的典型GUI表示将是文本字段和组合框（字符串，数字属性），列表/表（列表/表结构），标签（字符串），复选框和滑块（布尔型，整数）。
2.3.2服务的实施
JGadgets使用JGService类作为服务的抽象。服务与属性具有相同的属性，但缺少数据字段（见表1）。这是合理的，因为服务不包含数据。 JGService类也不是子类。
使用JGadgets框架中实现的服务方法perform（），在模型中激活服务。它不包含服务的实现，但只是启动机制。它检查服务是否处于活动状态（例如，启用的标志必须设置为true），并触发JGadgets操作事件，其中事件封装在ActionEvent类型的对象中。服务的实现包含在相应的事件处理方法中（参见小节2.5）。其原因是服务也可以在视图中激活，例如。当用户点击相应的视图元素（按钮或菜单项）时。由于视图中的激活是基于事件的，所以这种机制允许统一处理服务。
2.4链接模型和视图的命名约定
JGadgets使用命名约定将模型自动链接到视图：如果模型和视图元素具有相同的名
全文共21576字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[144927]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
