雀恰营销
专注中国网络营销推广

组件(基本组件、业务组件…)

组件(基本组件、业务组件…)

简介

组件(Component)是对数据和方法的简单封装。在 C++ Builder 中,组件是从 TComponent 派生的特定对象。组件可以有自己的属性和方法。属性是组件数据的简单访问器。方法是组件的一些简单且可见的功能。使用组件可以实现拖放式编程、快速属性处理和真正的面向对象设计。 VCL 和 CLX 组件是 C++ Builder 系统的核心。

组件分类

自己开发的组件通常分为三种:复合组件(Composite Controls)、扩展组件(Extended Controls)、自定义组件(Custom Controls)。

复合组件:将现有的各种组件组合成一个新的组件,它将集中集中化组件的性能。

扩展组件:从现有组件的入口衍生出一个新组件,为原有组件增加新的性能或改变原有组件的控制功能。

自定义组件:直接派生自 System.as windows.Forms.Control 类。 Control 类提供了组件所需的所有介绍性功能,包括键盘和鼠标事件处理。自定义组件是最灵活、最强大的方法,但是对开发者的要求比较高。您必须为 Control 类的 OnPaint 事件编写源代码。您还可以重写 Control 类的 WndProc 方法来处理较低级别的操作。 windows消息,所以你应该学习GDI+并制作windows API。

第三方控制

组件开发者应该掌握的三个主要内容是:属性、事件和方法。

由于组件开发的高度复杂性,专业的第三方控件会重写或扩展一些方法和属性来实现一些新的功能。需要设置不同的属性以完全适应特定项目的需要。常见的第三方控件包括表格控件、报表控件和用户界面控件。

用户界面组件

用于开发和构建用户界面(UI)的组件,帮助完成软件开发中的窗口、文本框、按钮、下拉菜单等界面元素的开发。

图表组件

用于开发图表的组件,帮助软件将数据可视化,实现开发过程中难以独立完成的复杂图表。

表示:用于 WinForm 的 ComponentOne Studio 图表。

报告组件

用于开发报表的组件,在软件中实现报表的查看、设计、编辑、打印等功能。

代表ActiveReports等

表格组件

专门用于开发表格(CELL)的组件,主要实现网格中数据处理和操作的功能。

代表:FlexGrid、Spread 等。

业务组件

业务组件是构建专业化企业不可分割的一系列业务活动和功能模块。业务组件的优势很大程度上来源于它们两个相关但又截然不同的特点:第一,组件之间通过松耦合链接,灵活、响应速度快、适用性强;二、组件内部各个活动的凝聚力强,能够对外提供高效优质的服务。

将业务活动分类为组件时要考虑的因素有:

● 类似的商业活动

● 使用相似数据

● 有一个共同的流程

● 一般业务目标

● 是密切相关的组织单位。通过组件共享,公司可以显着提高运营效率并增加竞争优势。

要深入了解业务之间的关系,并根据企业战略、管理和执行的要求进行分类。这需要良好的业务分类和分类能力,并考虑到业务之间的数据流动和共享。业务组件划分完成组件,系统功能设计和原型制作轻松!

企业应用下的业务组件开发实践 什么是企业应用下的业务组件

首先,这是一个组件,也就是说它需要在容器中运行,所以它不包含任何中间件服务,由一定的结构(文件结构或压缩格式)组成,被容器;其次,这是一个业务组件,即提供应用服务,而不是技术服务;第三,这是一个企业应用,包括业务上的功能和服务(Service,目前最流行的说法,可以理解为API),技术上(用J2EE的话),它包括:UI资源(JSF, JSP、JS和CSS等)、应用程序(Java)资源和配置文件、数据库表定义、初始化数据和存储过程。

为什么是企业应用下的业务组件

组件技术提出至今已有 20 多年。为什么要提到企业应用业务组件?因为现有的组件技术不支持企业应用环境中的组件需求,J2EE的EJB不支持,.NET的DLL也不支持。

如上所述,企业应用程序通常包括交互界面、应用程序代码和数据库结构,而无论EJB还是DLL只支持应用程序代码,不包括交互界面和数据库结构。

如果不是 EJB,那么 J2EE 的 EAR 或 WAR 是否被视为组件?答案是否定的,EAR 或 WAR 部署企业应用程序,请注意 EJB 规范明确指出:Enterprise JavaBeans 架构是用于开发和部署基于组件(分布式)的业务应用程序的架构(EJB 2. x 和 3.x 唯一的区别是 2.x 是分布式的),它们有自己的应用程序域,彼此隔离(简单来说,它们有自己独立的会话管理)。 .NET 也有自己的应用领域概念。

进一步,基于应用的部署会导致三个隔离问题:交互(接口)隔离、程序访问隔离、数据隔离(请注意组件(基本组件、业务组件…),这三个问题对应企业应用业务组件的三个技术内容)。交互隔离导致企业用户不得不访问不同的接口,代码访问隔离导致点对点集成以及性能、事务、异步处理等各种非功能性问题,数据隔离导致数据有效性、一致性和更多的。所有这些又会导致维护问题。

为了解决这些问题,大厂提出了各种解决方案:Portal解决交互隔离问题,ESB解决代码访问隔离问题,所谓Information Service解决数据隔离问题。

那么OSGi技术或者SCA技术能满足要求吗?目前还没有答案。 OSGi最初开发的目的不是为了企业应用,但是近几年已经成熟,正在向企业应用发展。 2009年推出的企业版(草案)刚刚提出了程序访问问题的解决方案,比如远程服务、事务管理等,规范没有针对交互隔离的问题提出相应的解决方案,只有Eclipse的Equinox提出了接口扩展点机制,但这也不能解决B/S环境的问题;并且没有解决数据隔离的问题。 SCA从一开始就面向企业应用,但并没有解决交互隔离和数据隔离的问题。

另外,对于行业ISV来说,除了企业用户面临的这些各种各样的问题之外,还有其他的问题。毕竟企业用户只面对自己的需求,而行业 ISV 面对的是多个企业用户的需求,并且面临定制化带来的维护问题,尤其是业务和技术的隔离(即如何维护用于构建的技术)业务组件。平滑升级)。

组件容器

由于我们需要企业应用下的业务组件,而现有的组件技术无法支持,所以我们需要一个新的组件容器(当然,作为一个普通的开发者,我们不能创建一个新的开放标准的组件系统,也要独立维护一个私人的)。新的组件容器完全使用了现有的中间件技术,加上一些新的内容,包括以下内容:

1.组件框架,识别组件,以及组件(文件)结构和单个技术工件。

2.技术框架,提供独立于业务的技术支持,方便技术的平滑升级和切换。

3.运行容器,使用现有的中间件技术,包括 Tomcat、应用服务器和数据库服务;

4.工具,包括打包和部署工具。

关于数据隔离的问题,EIP中提到了各种解决方案。这里采用的共享数据库方式,即每个组件共享一个数据库,每个组件只提供数据库定义和初始数据(如EJB/OSGi,运行时环境由容器提供)。

组件的关系

组件之间的关系分为依赖和链接两种。依赖关系在现有组件技术中得到了广泛认可,而链接则是新创建的(肯定不是第一个创建的,但不同的人有不同的名字)。

联动和依赖的区别在于:如果组件B和组件A是联动的,那么组件B可以在没有组件A的情况下运行并提供相应的功能。

三种不同的技术工件(即三个隔离问题)具有不同的特点,如下:

UI资源(交互隔离问题),依赖是指UI资源的嵌入、引用和替换,联动是指UI资源的添加。

Application(程序访问隔离),dependency指API/model依赖,linkage指message(传统消息和JMS消息)和SPI实现。其中,无论是依赖还是联动,都涉及到相应的非功能性需求,包括:异步、事务控制和服务时限。

数据库资源(数据隔离),依赖是指外键关联和级联操作,没有明显的联动关系。

这里需要注意应用依赖和链接

SPI 和 API 之间存在业务不匹配。

虽然A组件依赖B组件,但并不代表B组件提供的服务完全符合A组件的需求。有时A组件需要的数据需要由B组件的多个API组成。开发方便或者组件A需要的性能问题,可以在组件B中写一个新的接口供组件A使用。注意这个接口不是组件B的API。接口只对组件A可用。

尽可能使用 SPI 集成

SPI 集成方式是相对于 API 集成方式而言的。 API集成方式是组件B直接调用其他组件的API和模型。在SPI集成方式中(类似于依赖倒置),组件B定义了所需的接口及其模型,由组件A或胶水层代码实现。

对于行业 ISV 来说尤其如此。对于企业用户来说,依赖关系是明确的。组件 A 依赖/链接到组件 B,但对于行业 ISV,它面临定制问题。虽然组件A依赖/链接到组件B组件(基本组件、业务组件…),但在定制项目中,由于客户已有系统C,需要组件A依赖/链接客户现有系统C。此时使用SPI方法。

SPI 的采用在开源世界中更为广泛。很多框架为了兼容(相同功能)不同实现的类库,首先定义了框架需要的接口,同时为不同的类库提供胶水代码。

EJB/OSGi/SCA 都不支持 SPI 集成。

相关和链接的非功能性需求。

事实上,非功能性需求只存在于集成时。以事务管理为例,除了少数例子,大部分事务只能在处理流程中确定(注意EJB是在这方面定义在API上的,这样的设计不适合需求),很常见组件A的API在用例1中需要异步调用,在用例2中需要同步调用。甚至OSGi规范在这方面都没有做任何事情。

组件的自定义

定制问题仅对行业内的 ISV 有效。对于企业用户来说,除非是跨国公司面临不同国家的商业模式、法律监管和会计制度差异,否则就有定制化的需求。即便如此,ISV 和企业用户对同一个问题的解决方案也是不同的。

由于我们以组件化的方式开发原始应用程序,因此将应用程序定制问题转化为组件定制问题。同理,应用的定制化为组件的定制化。

组件框架

   罗罗嗦嗦的说了半天,有人就说了:这不就是把UI、Java和数据库三个东东一打包,然后说这就是一个企业应用下的业务组件,有啥新意呢,不就是模块化开发嘛,一直一来大家都是就是这么搞的嘛,何必搞个怪名词来忽悠。
   是的,就是把UI、Java和数据库三个东东整合在一起,组件容器说提到的技术框架很多的开发队伍都有一套,运行容器更是有无数开源商业的,打包部署工具更是写了无数。

这确实就是我们常说的模块化开发。但是,模块化开发不同于组件开发。模块化开发只是逻辑上的划分。物理上(开发的系统代码)通常没有真正的隔离,一切都在文档中。

我们需要一点干货,只有真正的组件框架才能真正实现组件开发(就像OSGi框架一样):我们需要一个类似于Equinox的接口扩展框架来支持UI资源的依赖和联动;我们需要一个集成框架来支持应用依赖和链接,解决面临的各种问题(业务不匹配,SPI集成,以及各种非功能性需求);我们需要一个打包的部署工具(类似于 Spring DM)来提供部署 UI 资源、Application 和数据库定义资源(Spring DM 提供了基于 web 的资源部署能力)。

其他问题

J2EE下使用B/S环境的组件应用还有一个问题,就是现有的Servlet规范只允许一个web.xml,不支持每个组件的自定义和私有Filter和Servlet组件,但这个问题不是很严重。现有的技术框架已经支持单个 web.xml,而新的 Servlet 规范已经允许多个 web.xml。

分布式部署和集群部署的问题,这个其实不是问题。我们有很多基于应用的方法和技术,所以也有基于组件的方法。

赞(0) 打赏
未经允许不得转载:雀恰营销 » 组件(基本组件、业务组件…)
分享到: 更多 (0)

评论 抢沙发

评论前必须登录!

 

文章对你有帮助就赞助我一下吧

支付宝扫一扫打赏

微信扫一扫打赏