发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA
1 2 下一页 Go 2

请教关于构件化动态组合开发的思路.

                   
2006-11-01 09:48
赞助商链接

想请教大家几个设计上的问题或者说是思路.
动机:由于现在公司业务比较广,原来的系统和业务功能一直在增加,
并且出现多个版本或者多个系统(因为功能相对无关联性),在管理和应用上出现很多问题.
那么现在公司提出想开发一个框架,它能够动态灵活的增加/删除子系统.
现在我有几个比较没主意的地方,需要大家帮助来帮助我。
1、如何动态增加/配置新的子系统?
例如:原来A系统包含任务管理功能,B系统包含仓库管理,C系统包含用户管理等.
那么有什么好的一个方式开发一个底层构架,能配置的方式任意选择其中A-C中的任一统来安装.

2、各个子系统的数据通信和控制?
如果在上面安装了A、C等系统,那么A和C的如何通信?
比如:我现在任务管理中想把任务分配给系统中的某个用户,那么必然要有个地方能让
我选择用户,一般我们假设为打开新窗口,那么A如何知道C模块用户列表的页面是哪个?
选择完后如何把选择的数据传回选择页面?

3、功能如何分布?
如果上面问题解决了,这个问题比较容易,就如上面的问题。
用户列表可能要屏蔽一些功能操作或者类似权限的问题,是放到C中还是A传递参数过去告知A该如何做?

2006-11-01 12:13


这实际上是我之前提出的“组件彻底可配置化”,也就是说:应用系统的每个组件或者类都是通过配置实现装配运行,当然,这首先需要一个Ioc或者依赖注射DI容器,也就是类或组件之间实现最大松耦合分离。

只有具体类是可配置的,然后我们可以认为任意划分归类,划分子系统,今天将ABC三个类归为1号系统,明天我可能将AHJK三个类归为1号系统,不同系统协调工作也简单。

对于你这个案例,如果你的ABC这几个系统不是建立在DI模式上,那么就只能采取传统方式进行硬的弥补。

两个系统协调工作不外乎数据库共享和系统之间通讯,数据库共享不用说,是最简单,系统通讯一般用JMS,JMS是可以将两个系统实现最大程度的松耦合,当然,使用JMS不可能让几个系统天衣无缝运行一起,这到底属于弥补,而不是融合。

总之一句话:要实现你构件化动态组合,必须前提都是将这些构件最大松耦合,而Ioc/DI是目前主流选择。

从你这个案例,也可以看出,我们什么现在Ioc/DI轻量框架会成为主流,其最重要的核心就是实现了构件的彻底可配置,完全可定制,进而才有根据需要动态组合这样高境界设计事情发生。

2006-11-01 14:00

首先感谢 banq 的热心回复.
我也是前几天开始接触JAVA,以前有关注过.但对于设计模式、IOC等这些概念还是有的.对于java实在比较陌生,最近一直有浏览这个网站,觉得e有很大的互动性,这也是为什么我在这边求教的原因.
昨天我有下载 jdon的框架下来看,包括PDF的参考文档.上面确实有很多的价值可以参考,暂时我还是要花时间把方向搞清楚,然后才决定如何使用或选择框架的问题.
或许目前面向构件设计系统的实例或者思想可能还不是很成熟,可能是我个人的能力原因。
我觉得界面控制和数据传输这方面感到很困惑。
比如上面提到的A要调用C的用户列表问题。
从业务方向来看A和C是存在一种关系,但系统方面应该保持独立(A不必知道C太多东西),这就有个问题:
1、谁来控制如何显示界面?
2、如何实现数据传输(包括格式)?
3、如果要调用的模块不在如何响应(当作错误?)。

我感觉不大可能把每个模块的每个界面的URL都配置进去吧?
希望有经验的前人,给我帮助或者建议!谢谢。

2006-11-02 09:55

全球领先的面向构件中间件提供商普元公司公布新消息,在继6月成为“服务构件架构”SCA国际构件标准组织中唯一的国内软件企业后,近日,又加入“服务数据对象”SDO国际构件标准组织,与IBM、BEA、Oracle、SAP等厂商协同,一起参与制定影响下一代企业数据编程的(Next-Generation Data Programming)架构与标准。
摘自:http://hi.baidu.com/%D2%F8%B5%AF/blog/item/3059b01b48b8e8198718bf51.html

上面这个引用,对这个贴子有什么作用呢?因为我需要开发的也是类似于此类系统框架.但我不知道国内是否还有更优秀的架构.
当然,我不知道有多少道友有使用或看过EOS的代码或者构架思想.至少我看过它的<EOS5.1程序员培训教程>后并没有让我拍手叫好(也没有说他不好,毕竟我还没有做个更好的或发现更好的).
这二天我主要也是在做这方面的学习,所以很希望大家给我帮助.

2006-11-02 10:20

你是刚刚接触Java,对于构件组件发展趋势可能不是非常明了,下面说说我对目前构件发展方向的想法:

目前构架发展有两种发展方向:
1. 构件轻量化发展方向,以DI/ioc为标志的组件管理方式,以Spring/JdonFramework/Jboss Seam,这方面是从设计思想上入手,所以一般不容易被初学者认识到好处,不会被初学者认为它是自己想像中的那样,但这不是问题,仔细研究就可以。参考一篇文章:

轻量企业应用框架 JBoss Seam
Lightweight Java Enterprise Application Frameworks: JBoss Seam

http://java.sys-con.com/read/180347.htm

作者认为轻量框架是未来发展方向,轻量应用开发框架是过去几年来Java社区的最大变化,从Spring Hibernate这样先锋,到AOP元注释metadata annotation推广,,一直到EJB 3.0(Java EE 5.0)等轻量框架正成为主流.

轻量框架的共同点是POJO模型,并且通过Ioc/Dependency Injection (DI)来实现POJO之间解耦。

主流轻量框架主要区别是他们如何实现容器内服务的配对和实现依赖的。The major differences between lightweight frameworks are how they wire container services together and implement Dependency Injection

2.以工业厂商为主导的SOA,因为有工业厂商的市场部门的潜移默化的宣传和普及,很多人初学者觉得这就是我想要的,SOA是基于系统通讯JMS等基础上的更复杂架构,这种架构无疑适合大型规模。

我个人以为:对于我们普通用户来说,更易用,简单化,而不是在一个复杂层面上再封装复杂层面,一层层叠加上去,这样的技术会很好,但肯定不好用,一个EJB2.0就把程序员搞得抓狂,大呼轻量化,SOA至少在其发展初期不见的简单。

任何一个伟大的技术总是在最初不会易用的,因为大家的精力是如何把功能做好,把这个新东西发明出来,然后才考虑易用,从EJB2.0到3.0也是这样,想开去,,电的发明;火车发明都是这个基本原理。


2Go 1 2 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com