面向对象应用系统框架详解与设计

需积分: 7 133 浏览量更新于2024-07-25 收藏 1.25MB PDF 举报

"《构建面向对象的应用软件系统框架》是一本深入探讨软件工程中系统框架设计的书籍，重点关注在开发应用软件时，特别是面向对象方法论的应用。该书分为三个主要部分：第一部分介绍了系统框架的总体概念、分层结构及其设计原则，包括应用服务层、数据实体表示、数据存取方式、业务逻辑处理以及层间交互等关键要素，并讨论了如何进行合理剪裁和选择。第二部分着重于应用服务层的设计，包括数据和对象的关系、对象/关系型映射（O/RMapping）的实施，如数据的不同状态管理和持久化策略。作者详细讲解了如何设计和实现一个O/RMapping框架，支持数据库访问层的封装、继承关系的处理，以及面向方面编程（AOP）的应用，如WebsharpAOP的实现和配置。此外，书中还涉及接口设计、事务处理和性能优化等内容，确保系统的稳定性和效率。第三部分关注用户界面层的设计，阐述了界面功能的划分、设计模式（如Model-View-Controller，MVC模式和页面控制器），以及动态代码生成和编译技术，如Emmit和CodeDom。同时，书中还介绍了远程过程访问（如WebService和.NET Remoting）的集成，以提升用户界面的交互性和可扩展性。通过这本书，读者将学习到如何构建稳健、模块化的面向对象应用软件系统框架，理解和掌握关键的设计原则和技术实践，从而提高软件开发的效率和质量。"

实际操纵数据库的时候，需要编写大量的代码，并且，我们还需要通过手工的方式来完成将

程序中的面向对象的数据存储到关系型数据库的工作。这么做，自然编程的效率不高，并且

非常容易出错。但是，不可否认，这也是一种可以选用的方式。

从另外一个方面来看，由于我们前面已经解决了数据的映射问题，因此，在数据的存取

方面是非常有规律的，我们完全可以让这个工作通过框架来执行。这样，我们一方面可以简

化很多同数据库交互方面的代码编写工作量，能够减少出现 Bug 的几率，另一方面，由于

框架封装了不同数据库之间的差异，使得我们在编写程序的时候，不用考虑不同数据库之间

的差异，而将这个工作交给框架去做，实现软件的后台数据库无关性。

在这个部分，以下两个部分的类会显得特别重要：

◆对象--关系映射的分析类，能够通过既定的方案完成对象--关系的映射，确定数据存

取方案

◆数据库操纵类：根据映射关系，将数据准确的存储到数据库中，并且封装不同数据库

之间的差异。

这个部分的操作过程，可以用图(图 2.3)大概的表示如下：

图 2.3

在J2EE 中，这个部分比较典型的就是 EntityBean 中的 CMP。由于在 BMP 中，同数

据库的交互部分需要通过手工编写代码的方式来实现，因此，很难享受到容器带来的便利，

只是由于 EJB2.0 以前的标准，CMP 的功能，包括映射能力、实体关系模式等方面的功能

比较弱，所以，在很多时候，我们不得不使用 BMP。现在，EJB2.0，在这个方面的功能已

经非常强大了，我们完全可以享受容器带来的便利，而将大部分精力放在实现更加复杂的业

务逻辑方面了。

值得指出的是，很多人在这个部分操纵数据库，把业务逻辑处理等同于数据库操作，这

是不可取的。在业务逻辑处理中，处理的应该是对象，而不是直接同数据库打交道，这样，

才能获得更好的系统结构。

在业务逻辑处理部分，由框架提供一些支撑的服务是非常必要的。这其中，最重要的一

点就是事务的处理。业务逻辑的处理过程，会涉及到多个对象之间的交互，以及多次同数据

库的交互。为了保证处理过程的完整性，必须使用事务处理的方法。框架必须支持事务处理。

事务处理的功能，基本上有两种选择：使用基于数据库连接的事务、使用外部事物处理

服务

[12]

。

使用基于数据库连接的事务，事务处理的性能相对比较高，但是，当系统涉及到多个数

据库之间的交互时，基于数据库连接的事务便无能为力了。而使用专用的事务处理服务，能

够适应更多的情况，并且，有测试表明，随着数据处理量的上升，两者之间的性能差异会逐

渐减小。

在J2EE 中，容器提供了事务处理的能力。在.Net 平台上，事务处理是通过 Windows

COM+服务来提供的。在 Websharp 中，如上面所讲，通过 Transaction 接口，提供了基本

的事务处理能力，能够满足大部分事务处理的要求。当 Websharp 提供的事务处理能力不能

满足需求的时候，可以使用 EnterpriseService。

下面是一个简单的例子：

public bool AddSchdule(Schdule schdule,string[] otherPeoples)

{

if(!CheckSchdule(schdule))

return false;

PersistenceManager pm =

PersistenceManagerFactory.Instance().CreatePersistenceManager();

Transaction trans = pm.CurrentTransaction;

trans.Begin();

try

{

pm.PersistNewObject(schdule);

foreach(string otherPeople in otherPeoples)

{

Schdule s = EntityManager.CreateObject(typeof(Schdule)) as Schdule;

s.GUID = Guid.NewGuid().ToString();

s.UserID = otherPeople;

s.StartTime = schdule.StartTime;

s.EndTime = schdule.StartTime;

s.Title = schdule.Title;

s.Description = schdule.Description;

s.RemidTime = schdule.RemidTime;

s.AddTime = DateTime.Now;

s.Status = 0;

pm.PersistNewObject(s);

}

trans.Commit();

return true;

}

catch

{

trans.Rollback();

return false;

}

finally

{

pm.Close();

}

在业务逻辑这一层，另外一个需要关注的问题是所谓的 AOP。关于 AOP 的内容，我们

会在下面的章节中再讨论。

2．7．业务服务的提供

业务外观层（Business Facade）的目的，是隔离系统功能的提供者和使用者，更明确

地说，是隔离业务逻辑的软件的用户界面（可以参见 Facade 设计模式）。这一层没有任何

需要处理的逻辑，只是作为后台逻辑处理和前端用户界面的缓冲区，以达到如下目的

◆将用户界面和系统业务逻辑处理分开，这样，当业务逻辑发生变化时，不用修改客户

端程序，是一种支持变化的设计方法。

◆使同一个业务逻辑能够处理不同的客户端请求。例如，可以将 Facade 设计成 Web

Service，这样，可以同时为传统的 WinForm 客户端程序、Web 程序以及其他外部系统提

供服务，而使用相同的应用服务层，同时，也可以实现系统的分布式部署。关于如何做到这

一点，可以参见 Ioffice 的 Demo 程序。

◆作为系统不同模块之间的调用接口。一个系统通常会包含很多模块，这些模块相对独

立，又可能互相调用。为了减少各个不同部分之间的耦合度，必须采用一定的设计方法，

Facade 设计模式就是非常有效的一种，也是业务外观层的基础。

◆有利于项目团队的分工协作。业务外观层作为一个访问接口，将界面设计人员和逻辑

设计人员分开，使得系统的开发可以实现纵向的分工，不同的开发人员可以关注自己的领域

而不会受到干扰。

业务外观层的代码框架，在系统分析和设计完成后就可以完成，他需要提供的方法，就

相当于在界面设计人员和逻辑设计人员之间签订了一个协议，他虽然没有实现任何逻辑，但

剩余150页未读，继续阅读

zhenwenl_USTC

粉丝: 3
资源: 28

面向对象应用系统框架详解与设计

构建面向对象的应用软件系统框架.doc

"构建面向对象的应用软件系统框架

面向对象应用软件系统框架设计与实现

面向对象应用软件系统框架设计与实践

面向对象应用软件系统框架详解与设计策略

CPPC++_作为反向代理来保护您的web服务免受攻击和利用.zip

CPPC++_原生macOS HD音频，不支持官方编解码器.zip

Matlab实现黏菌优化算法SMA-TCN-Multihead-Attention多输入单输出回归预测算法研究.rar

【SCI2区】基于花朵授粉优化算法FPA优化TCN锂电池健康寿命预测算法研究Matlab实现.rar

临时项目:使用python进行自动网页抢票,包含selenium的调用,cookie获取以及网页信息全识别.zip

最新资源