废除“竖井”转向“SOA” 为什么要采用SOA

本文探讨了面向服务的架构(SOA)作为解决企业IT资源整合和共享问题的一种方式。SOA通过模块化和开放标准接口设计,实现IT与业务的紧密结合,提高业务流程的灵活性。文章详细介绍了SOA的7层架构,包括系统资源、组件、服务、商业流程、表示层、企业服务总线(ESB)及辅助功能层。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

   目前主流的软件项目的架构类似“竖井”,在这个“竖井”中有数据库,中间层、客户端表现层等。每个应用系统的数据库分属在不同的竖井中,当我们的信息化发展到一定程度,已开发和上线运行的系统需要整合或实现数据共享时,我们不得不在竖井中“穿洞”透过不同的“竖井”来访问数据库。一个数据库中的对象发生了变化,对其他系统的影响就变得“不可知”和“不可控”了。



    当我们想调用系统的服务时也要突破竖井。如果将企业的IT资源,如:客户端程序、中间层业务处理、支撑平台、数据处理、原始数据和规范数据源,按照分层再通过消息机制将各个应用系统的这个资源都整合在一起,根据每一层不同的功能和作用统一组织在一起。

     我们现在使用新的设计思想,SOA是面向服务的体系架构,更确切地说是一种架构的风格;SOA是一种风格和理念,强调的是资源共享和复用、企业架构动态和柔性的组合;SOA通过模块化和开放标准接口设计,使企业实现IT与业务紧密结合,提高企业业务流程的灵活性。

 


     SOA 系统中不同的功能模块可以被分为7:第一层就是系统已经存在的程序资源,例如ERP或者CRM系统等。第2层就是组件层,在这一层中我们用不同的组件把底层系统的功能封装起来。第3层就是 SOA 系统中最重要的服务层,在这层中我们要用底层功能组件来构建我们所需要的不同功能的服务。总的来说,SOA 中的服务可以被映射成具体系统中的任何功能模块,但是从功能性方面可以大致划分为以下三种类型:(1)商业服务(business service) 或者是商业过程(business process)。这一类的服务是一个企业可以暴露给外部用户或者合作伙伴使用的服务。比如说提交贷款申请,用户信用检查,贷款信用查询。(2)商业功能服务(business function service) 这类服务会完成一些具体的商业操作,也会被更上层的商业服务调用,不过大多数情况下这类服务不会暴露给外部用户直接调用,比如说检索用户帐户信息,存储用户信息等。(3)技术功能服务(technical function service),这类服务主要完成一些底层的技术功能,比如说日志服务以及安全服务等。在服务层之上的第4层就是商业流程层,在这一层中我们利用已经封装好的各种服务来构建商业系统中的商业流程。在商业流程层之上的就是第5层表示层了,我们利用表示层来向用户提供用户接口服务,这一层可以用基于portal的系统来构建。以上这5层都需要有一个集成的环境来支持它们的运行,第6层中的企业服务总线(ESB)提供了这个功能。第7层主要为整个 SOA 系统提供一些辅助的功能,例如服务质量管理,安全管理这一类的辅助功能。

转载于:https://www.cnblogs.com/utopia/archive/2009/09/02/1558703.html

<think>嗯,用户想知道为什么在NHibernate的3.5.1版本中,extractModelClass被废弃了,以及替代方案是什么。首先,我需要回忆一下NHibernate的相关知识,或者查看提供的引用内容。 根据引用3,NHibernate通过标识符的属性值来区分新实例和已存在的实例,这可能涉及到实体类的映射配置。不过用户的问题是关于extractModelClass的废弃,这可能涉及到API的变化或者设计模的改进。 在引用1中提到,混合API在大多数情况下比动态API更好,除非是在实现库作为代理的情况下。可能NHibernate在3.5.1版本中改进了API设计,推荐使用更高效或更清晰的方,导致旧的extractModelClass方法被废弃。 引用2提到了通过装饰器导入类,这可能与实体类的注册或映射方有关。也许新的版本引入了更简洁的注解方,取代了之前需要手动提取模型类的步骤。 综合来看,extractModelClass可能属于旧的动态API或映射配置的一部分,而新版本推荐使用更声明的方法,比如通过属性或注解来自动处理,减少手动提取的需要。替代方案可能涉及使用新的装饰器或配置属性,如Import特性,或者利用NHibernate的自动映射功能。 需要确认extractModelClass的具体作用。通常,这类方法用于从映射文件中提取模型类,可能在新版本中,框架能够自动推断模型类,无需显提取,因此该方法被标记为过时。替代方案可能是直接在映射配置中使用类名,或者通过元数据自动处理。 因此,废弃原因可能是为了简化API,提升易用性,减少冗余代码。替代方法可能涉及使用更现代的映射技术或注解,如Fluent NHibernate或Conformist配置,或者框架内部自动处理模型类的提取,无需用户手动调用。</think>### extractModelClass 在 NHibernate 3.5.1 中被废弃的原因与替代方案 #### 1. 废弃原因 `extractModelClass` 方法在 NHibernate 3.5.1 中被废弃,主要与以下设计改进相关: - **API 简化与统一性**:NHibernate 3.5.1 开始推动更简洁的配置方,推荐使用声明注解(如 `[Import]`)替代手动提取模型类的操作[^2]。 - **自动类型推断增强**:新版本通过映射元数据(如 `<id>` 或 `<version>` 配置)自动识别模型类,减少手动干预需求[^3]。 - **动态 API 的优化**:混合 API(Hybrid API)逐渐取代动态 API,提供更清晰的类型安全性和代码结构[^1]。 #### 2. 替代方案 以下是两种主要替代方法: ##### 方法 1:使用 `[Import]` 注解声明依赖类 通过装饰器直接绑定模型类,例如: ```csharp [Import(ClassType = typeof(YourModelClass))] public class YourEntity { // 实体属性与映射 } ``` 此方将依赖关系显声明在类级别,符合 NHibernate 3.5+ 的推荐实践。 ##### 方法 2:通过映射文件隐注册 在 `.hbm.xml` 文件中直接指定类名,利用 `<class>...</class>` 标签完成映射: ```xml <hibernate-mapping> <class name="YourNamespace.YourModelClass, YourAssembly"> <!-- 映射字段 --> </class> </hibernate-mapping> ``` NHibernate 会自动解析类型,无需手动提取。 #### 3. 迁移注意事项 - **兼容性检查**:确保新配置方与现有代码的 `unsaved-value` 等标识逻辑兼容。 - **单元测试验证**:重点测试实体加载、保存和查询功能是否正常。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值