Java企业系统架构选择考量
基于Java的ERP系统开发实践经验分享
基于Java的ERP系统开发实践经验分享近年来，随着互联网技术的快速发展，越来越多的企业开始使用ERP系统来管理日常业务。
在这个过程中，Java作为一种高效、安全、开源的编程语言，成为很多企业开发ERP系统的首选语言。
本文将分享基于Java的ERP系统开发实践经验。
一、需求分析在ERP系统开发之前，我们需要仔细分析客户的需求。
我们需要了解客户的业务流程，以及他们的需求和期望。
这些信息对于系统的设计和开发至关重要，因为它们将驱动整个项目。
二、架构设计在系统分析的基础上，我们需要进行系统架构设计。
系统架构设计是一个关键的步骤，因为它将决定系统的稳定性和可扩展性。
在基于Java的ERP系统中，我们通常使用MVC模式。
MVC模式将客户端的用户界面、业务逻辑和数据管理分离，使得系统更加灵活和可扩展。
Model层主要负责数据的存储和管理，View层则负责显示数据和接收用户输入，Controller层则是连接Model和View的桥梁。
三、数据库设计ERP系统中的数据通常非常复杂，因此数据库设计是至关重要的。
在设计数据库时，我们需要考虑数据之间的关系和依赖性，以及数据表之间的索引和索引优化。
同时，我们需要处理大量的数据，因此我们需要考虑如何有效地使用数据库缓存和数据库分区。
四、开发过程在架构和数据库设计完成之后，我们开始进行系统的开发。
在这个过程中，我们需要保证代码的质量，并通过单元测试和代码审查来确保代码的正确性。
为了加快开发进度，我们通常会使用一些成熟的开源框架，如Hibernate、Spring和Struts等。
这些框架可以协助我们管理数据库和实现业务逻辑，从而节省时间和提高开发效率。
五、部署和维护ERP系统的部署和维护同样非常关键。
在部署过程中，我们将系统部署到Web服务器上，并进行性能测试来确保系统的可靠性和稳定性。
在维护过程中，我们需要定期进行系统备份和监控，以确保系统的运行状况。
六、总结基于Java的ERP系统开发需要我们具备深入的技术知识和非常强的团队合作能力。
四种常见的系统架构
软件架构（software architecture）就是软件的基本结构。
合适的架构是软件成功的最重要因素之一。
大型软件公司通常有专门的架构师职位（architect），只有资深程序员才可以担任。
如果一个软件开发人员，不了解软件架构的演进，会制约技术的选型和开发人员的生存、晋升空间。
这里我列举了目前主要的4种软件架构以及他们的优缺点，希望能够帮助软件开发人员拓展知识面。
一、单体架构单体架构比较初级，典型的三级架构，前端(Web/手机端)+中间业务逻辑层+数据库层。
这是一种典型的Java Spring mvc或者Python Drango框架的应用。
其架构图如下所示：单体架构单体架构的应用比较容易部署、测试，在项目的初期，单体应用可以很好地运行。
然而，随着需求的不断增加，越来越多的人加入开发团队，代码库也在飞速地膨胀。
慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。
下面是单体架构应用的一些缺点：复杂性高：以一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起。
可想而知整个项目非常复杂。
每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个Bug都会带来隐含的缺陷。
技术债务：随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。
“ 不坏不修”，这在软件开发中非常常见，在单体应用中这种思想更甚。
已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。
部署频率低：随着代码的增多，构建和部署的时间也会增加。
而在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。
全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低。
而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。
可靠性差：某个应用Bug，例如死循环、内存溢出等，可能会导致整个应用的崩溃。
基于Java的企业级信息管理系统开发与优化
基于Java的企业级信息管理系统开发与优化企业级信息管理系统是企业内部管理的重要工具，它可以帮助企业高效地管理各种信息资源，提升工作效率和管理水平。
在当今信息化的时代，企业级信息管理系统的开发和优化显得尤为重要。
本文将从Java语言的角度出发，探讨企业级信息管理系统的开发与优化。
1. Java在企业级信息管理系统中的应用Java作为一种跨平台、面向对象、高性能的编程语言，在企业级信息管理系统的开发中有着广泛的应用。
其优秀的特性使得Java成为企业级应用开发的首选语言之一。
在企业级信息管理系统中，Java可以应用于后端服务端开发、前端界面开发、数据库连接等多个方面。
1.1 后端服务端开发在企业级信息管理系统中，后端服务端承担着处理业务逻辑、数据存储和交互等重要功能。
Java通过其丰富的类库和框架（如Spring、Spring Boot等），可以快速地搭建稳定高效的后端服务端。
同时，Java的多线程特性也使得后端服务端能够更好地支持并发访问，保证系统的稳定性和性能。
1.2 前端界面开发企业级信息管理系统的前端界面是用户与系统交互的窗口，Java通过其前端框架（如Spring MVC、Thymeleaf等）可以实现页面的动态展示和交互。
同时，Java与JavaScript等前端语言结合使用，可以实现更加丰富多彩的前端界面效果，提升用户体验。
1.3 数据库连接企业级信息管理系统需要与数据库进行数据交互，Java通过JDBC、Hibernate等技术可以方便地连接各种类型的数据库，并进行数据的读写操作。
Java对数据库事务的支持也使得数据操作更加安全可靠。
2. 企业级信息管理系统开发流程企业级信息管理系统的开发是一个复杂而系统的过程，需要经过需求分析、设计、编码、测试、部署等多个阶段。
下面将介绍企业级信息管理系统开发的主要流程。
2.1 需求分析需求分析是企业级信息管理系统开发的第一步，需要与客户充分沟通，了解客户需求和期望。
基于Java的物流管理系统设计与实现
基于Java的物流管理系统设计与实现一、引言随着电子商务的快速发展，物流行业也迎来了前所未有的发展机遇和挑战。
为了提高物流运输效率、降低成本、提升服务质量，许多物流企业开始引入信息技术，建立物流管理系统。
本文将介绍基于Java的物流管理系统的设计与实现，探讨其在物流行业中的重要性和应用前景。
二、系统架构设计1. 系统功能模块订单管理模块：包括订单下单、订单查询、订单修改等功能。
货物管理模块：包括货物入库、出库、库存管理等功能。
车辆调度模块：包括车辆分配、路线规划、运输跟踪等功能。
人员管理模块：包括司机信息管理、仓库人员管理等功能。
报表统计模块：包括运输报表、库存报表、成本统计等功能。
2. 技术选型后端框架：Spring Boot数据库：MySQLORM框架：MyBatis前端框架：Vue.js消息队列：RabbitMQ分布式缓存：Redis3. 系统架构图示例代码star：编程语言：待补充系统架构图示例代码end三、系统实现1. 后端开发(1) Spring Boot搭建首先搭建Spring Boot项目，配置相关依赖和数据库连接信息。
使用Spring框架实现各个功能模块的业务逻辑，采用RESTful风格设计接口。
(2) 数据库设计与MyBatis集成根据系统需求设计数据库表结构，使用MyBatis框架进行数据库操作。
通过XML文件编写SQL语句，实现数据的增删改查操作。
(3) 消息队列应用利用RabbitMQ实现订单状态更新消息的异步处理，提高系统的并发能力和稳定性。
2. 前端开发(1) Vue.js框架搭建使用Vue.js框架搭建前端页面，实现用户订单管理、货物查询等功能。
通过组件化开发提高页面的复用性和可维护性。
(2) 前后端数据交互通过RESTful接口实现前后端数据的交互，实现数据的动态展示和更新。
利用Axios库发送HTTP请求，获取后端数据并展示在页面上。
3. 系统测试与部署(1) 单元测试与集成测试编写单元测试和集成测试用例，保证系统各个模块的功能正常运行。
系统架构师常见面试题
系统架构师常见面试题在当今科技飞速发展的时代，系统架构师在企业的技术领域中扮演着至关重要的角色。
他们负责设计、构建和维护复杂的系统架构，以确保系统的高效、稳定和可扩展性。
因此，在招聘系统架构师时，面试环节通常会涉及一系列具有挑战性的问题，以评估候选人的技术能力、经验和解决问题的思维方式。
以下是一些常见的系统架构师面试题：一、技术基础和原理1、请简要介绍一下常见的分布式系统架构模式，例如主从模式、对等模式和分布式哈希表（DHT），并说明它们的优缺点。
这道题旨在考察候选人对分布式系统基本架构模式的理解和掌握程度。
主从模式具有易于管理和控制的优点，但存在单点故障的风险；对等模式具有高容错性和可扩展性，但协调和管理相对复杂；DHT 则在大规模分布式系统中表现出色，但其实现和维护较为复杂。
2、谈谈你对数据库索引的理解，包括 B 树索引、哈希索引和位图索引的工作原理及适用场景。
数据库索引是提高数据库查询性能的关键。
B 树索引适用于范围查询和排序操作；哈希索引适用于等值查询，但不支持范围查询；位图索引则在处理低基数列和大量重复值时效率较高。
3、解释一下什么是 CAP 定理，并阐述在实际系统设计中如何权衡一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）。
CAP 定理指出在分布式系统中，最多只能同时满足这三个特性中的两个。
在实际设计中，需要根据系统的需求和业务场景来决定侧重哪两个特性。
例如，对于金融交易系统，可能更注重一致性和可用性；而对于大规模的社交网络，可能会更倾向于可用性和分区容错性。
二、系统设计与架构1、假设要设计一个高并发的电商网站，你会如何考虑系统的架构？包括前端、后端、数据库和缓存等方面。
对于前端，要考虑使用 CDN 加速静态资源的加载，采用响应式设计以适应不同设备；后端可以采用微服务架构，将不同的功能模块拆分成独立的服务；数据库要进行读写分离和分库分表以应对高并发读写；缓存可以使用 Redis 来存储热门商品和用户频繁访问的数据。
系统架构设计师招聘面试题与参考回答(某大型央企)2025年
2025年招聘系统架构设计师面试题与参考回答(某大型央企)(答案在后面)面试问答题（总共10个问题）第一题题目描述：请简述您在系统架构设计中如何确保系统的稳定性和可扩展性，并举例说明在实际项目中是如何实施的。
第二题题目描述：请描述在大型系统架构设计中，如何平衡系统的可用性与稳定性？请提供具体策略和可能的挑战。
结合你过往的工作经验或理论知识加以说明。
答案及解析：第三题题目：在您过去的工作经历中，您曾经参与过哪些招聘系统的设计和实施？请详细描述其中一个您认为最成功的案例，并说明您在其中的具体贡献和所遇到的挑战，以及您是如何解决这些挑战的。
参考答案及解析：第四题题目：在构建一个高效、可扩展的招聘系统时，如何确保系统的安全性？请结合你过去的项目经验，谈谈你的看法和解决方案。
参考答案及解析：第五题问题描述：假设你是一家大型央企的招聘系统架构设计师，负责设计一个新的招聘流程系统。
该系统需要支持线上简历筛选、面试安排、录用通知发放等功能，并且要求系统具有良好的扩展性和稳定性。
请简述你的系统架构设计方案，并说明你如何确保系统的可扩展性和稳定性。
参考答案及解析：第六题题目：请描述在大型系统中如何进行系统架构设计的流程，并举例说明在架构设计过程中遇到的一个技术难题及其解决方案。
第七题•问题：请谈谈您对微服务架构的理解，并结合您过去的工作经验，描述在大型央企中实施微服务架构的挑战和策略。
第八题题目：在设计和实施一个招聘系统时，如何确保系统的安全性和可靠性？参考答案及解析：第九题题目：在招聘系统中，如何设计一个高效且可扩展的用户认证与授权模块？参考答案及解析：第十题题目：在构建一个高效、可扩展的招聘系统时，如何确保系统的安全性？请结合您在大型央企的工作经验，谈谈您的看法和经验。
参考答案及解析：2025年招聘系统架构设计师面试题与参考回答(某大型央企)面试问答题（总共10个问题）第一题题目描述：请简述您在系统架构设计中如何确保系统的稳定性和可扩展性，并举例说明在实际项目中是如何实施的。
java管理系统设计参考文献
Java管理系统设计参考文献引言Java作为一种功能强大、可靠性高的编程语言，被广泛应用于各种软件系统的开发中。
在管理系统开发方面，Java具备了许多独特的优势，其丰富的类库和良好的跨平台特性使得Java成为了开发管理系统的首选语言之一。
本文将对Java管理系统设计方面的相关参考文献进行综述，以供相关开发人员参考。
参考文献列表以下是一些研究Java管理系统设计方面的重要参考文献：1.Zhang, Y., & Zhang, Y. (2017). Design and Implementation ofDistributed E-commerce Management System Based on Java. Journal ofTheoretical & Applied Information Technology, 95(6), 1271-1280.这篇文献描述了基于Java的分布式电子商务管理系统的设计与实现。
文中介绍了该系统的架构设计、技术选择和关键功能的实现方式。
该文献对于开发分布式管理系统的开发人员具有很高的参考价值。
2.Chen, X., & Liu, H. (2018). Design and Implementation of Java-basedHospital Management System. Advances in Computer Science Research, 72,801-806.这篇文献重点介绍了一个基于Java的医院管理系统的设计与实现。
文中详细讲解了系统的需求分析、系统架构设计以及核心功能的开发过程。
通过该文献可以了解到如何运用Java开发复杂而完整的管理系统。
3.Wang, L., & Wang, N. (2019). Design and Implementation of Java-based Inventory Management System. Journal of Software Engineering, 83,426-432.这篇文献针对使用Java开发库存管理系统进行了设计与实现。
Windchill系统架构介绍
© 2007 JWI
FileVault
•PDMLink •ProjectLink •PartsLink •ProductView •WGM •Web server •Tomcat •File vault •Oracle •Third part Software
Windchill 9.1 WEB Server LDAP Server DB Server
CRM
Web服务
其他Windchill 服务器： --Federation --Replication 其他API: --消息 --主机 --邮件服务 器 --其他PDM --LDAP支持
© 2007 JWI
硬件架构
AD Server
Mail Server
VSS Server
12
PLM Server
新产品引入 (新产品开发全过程, 关注基本的工作方式, 关注评审点) 变型产品开发过程 变更管理 (关注变更的完整性和事后的总结)
需求响应 (与销售部门的业务流程) 新零部件引入 (关注标准化, 控制新零部件引入数量, 提高重用性) 研发与制造衔接 制造过程外包 (关注与供应商的协同) 系统设计 (关注平台, 接口, 重用, 选配) 售后服务流程
流程管理工具
活动, 子活动 或, 与, 阀值, 条件转移, 接地 方法自动机, 定时器, 启动应用程序, 执行表达式, 同步, URL自动机, 电子邮件通知
Java企业级开发-考核方案
《Java企业级开发》考核方案——计算机科学与技术（应用软件开发）一、分组要求1．各班自由结合分组，不允许跨班组合，3-4人一组。
2．每组可以基于教师布置的课题进行设计，也可以自主选择项目开展系统设计，但均要求基于MVC框架来实现。
二、大作业内容要求（一）项目需求分析1、业务流程图：给出核心业务的流程图2、功能性需求：可以以文字或者列表等形式陈述项目功能性需求（二）项目系统设计1、系统功能模块图2、系统功能描述：可以是表格或图片等形式（三）项目数据库设计1、E-R图2、数据库表（四）项目实现情况1、核心代码：能够体现MVC三层设计思想，尤其要给出控制器代码。
2、系统运行三、大作业提交要求1．提交内容和时间安排：课程大作业最终提交材料：（1）课程大作业文档：命名规则“组长学号-组长姓名.doc”（2）各组于6月15日之前提交纸质稿给学委，学委6月16日前将打印稿整理好送至老师办公室。
四、评分标准课程总成绩=平时成绩（30%）+课程大作业（70%）：1．平时成绩（30%）根据平时出勤、提问、实验报告和课堂表现综合评定。
2．提交课程大作业（70%）要求学生独立完成，有抄袭或雷同本项不得分；（1）系统功能完整、分析得当，设计正确、架构清晰简洁，框架整合正确，编码有规范，项目截图清晰；（30’）（2）项目模型层代码清楚，陈述准确，能够体现javabean技术；（10’）（3）项目视图层代码清楚，放置于WEB-INF目录下，结构清晰；（10’）（4）项目控制层各控制器定义准确，逻辑方法处理合理；（20’）（5）Struts的配置文件配置过程清晰，准确；（10’）（6）文档符合规范，格式标准，内容完整；（15’）（7）作业提交及时、准确。
（5’）李恋2018年5月16日。
系统总体解决方案(3篇)
第1篇一、引言随着信息技术的飞速发展，企业对信息系统的依赖程度越来越高。
一个高效、稳定、安全的系统对于企业的发展至关重要。
为了满足企业日益增长的需求，本文将针对企业信息系统的建设，提出一个系统总体解决方案，旨在提高企业信息系统的整体性能和用户体验。
二、系统需求分析1. 系统功能需求（1）基础功能：系统应具备用户管理、权限管理、数据备份与恢复、日志管理等功能，确保系统的正常运行。
（2）业务功能：根据企业业务需求，系统应具备订单管理、库存管理、财务管理、人力资源管理等模块，以满足企业各部门的日常工作需求。
（3）数据集成与交换：系统应具备与其他系统集成与交换数据的能力，实现数据共享和业务协同。
2. 系统性能需求（1）响应速度：系统应具备快速响应的能力，确保用户在使用过程中能够得到及时、准确的信息。
（2）稳定性：系统应具备高稳定性，减少故障发生，确保企业业务的连续性。
（3）安全性：系统应具备完善的安全机制，保障企业数据的安全性和完整性。
3. 系统可扩展性需求（1）模块化设计：系统应采用模块化设计，便于后期扩展和维护。
（2）技术选型：采用成熟、稳定的技术架构，为系统扩展提供技术保障。
三、系统架构设计1. 系统架构概述本系统采用分层架构，分为表现层、业务逻辑层、数据访问层和数据库层。
（1）表现层：负责用户界面展示，包括Web界面、移动端界面等。
（2）业务逻辑层：负责处理业务逻辑，实现系统核心功能。
（3）数据访问层：负责与数据库进行交互，实现数据存储和查询。
（4）数据库层：负责存储企业业务数据。
2. 技术选型（1）前端技术：HTML5、CSS3、JavaScript、Vue.js、React等。
（2）后端技术：Java、Spring Boot、MyBatis、Dubbo等。
（3）数据库技术：MySQL、Oracle、MongoDB等。
（4）中间件技术：Redis、RabbitMQ、Zookeeper等。
四、系统功能模块设计1. 用户管理模块（1）功能描述：实现用户注册、登录、权限分配、用户信息修改等功能。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Java企业系统架构选择考量 现在Java领域各种技术百花齐放，名目繁多，如何根据自己的需求选择这些框架呢？特别对于初学者，在学习选择方向上也非常迷茫，如何有针对性的根据自己项目特点进行学习就变的更加重要。
下面我们从一个发展角度来对J2EE/Java EE的这些框架诞生进行一番考量，可能对我们的选择有很大帮助。
首先我们需要明白一个高质量的J2EE系统是什么样子？高质量的J2EE/Java EE系统标准实际就是OO设计的标准，松耦合是OO设计的主要追求目标之一，那么无疑解耦性成为衡量J2EE/JEE质量的首要标准。实际选择中，还需要兼顾可伸缩性/性能/开发效率等方面综合考虑。
J2EE/Java EE号称多层结构，为什么多层比两层好？因为多层结构解耦性好，带来维护拓展方便灵活。
典型的J2EE/Java EE至少划分三个层次：表现层/业务逻辑组件层/持久层。 如图，表现层英文是Presentation Layer，是实现显示功能的，这部分一般使用B/S结构来完成，当然你也可以使用专门远程客户端来实现;
业务逻辑层因为是由大量组件(Components)组成的，也可称为组件层，组件从不同角度又可分为各种类型，然后又有不同的流派，目前占主要位置的是Model+Service，模型加服务，所以这一层又称为业务服务层Business Service；也有称为Model业务层；
持久层是负责对象持久化也就是数据库操作的层次,英文Persistence Layer。 SUN伙伴们推出J2EE标准时，分别对这三个层次规定了标准实现，表现层使用Jsp/Servlet技术；业务组件层使用EJB的会话Bean；持久层使用实体Bean。同时，标准将业务层和持久层在物理上组成一个新的容器EJB容器，与表现层技术完全一样的容器，这样，J2EE技术被细化为Web和EJB，物理上有Web容器和Web应用程序；以及EJB容器和EJB应用程序。
当然，J2EE/JEE的发展不止这些，这三个层次技术分别独立发展，高歌猛进，下面分别单独陈述，当你了解某种框架技术为什么诞生时，你可能就知道你该在什么情况下选择它们了，工具总是因目的而生！
表现层框架 J2EE/Java EE虽是多层结构，但它不是一种强制性多层结构，也就是说，你也可能做成传统两层结构，有的初学者直接使用Jsp嵌入Java代码调用数据库这样结构实际不是多层结构，还是以前的两层结构。 在Jsp中嵌入大量代码，一旦报空指针错误就很难找出问题，很多初学者下载JiveJdon 2.5后就经常碰到这个问题，因此大量有关空指针错误问题出现论坛里，为什么他们不能自己解决呢？ 那是因为无法定位错误在Jsp中的位置，Tomcat等服务器只告诉我们错误在index_jsp.java(Jsp的java文件)位置，搞得一些人经常会跑到Tomcat服务器内部翻找Jsp的Java文件，这一过程无比痛苦（为了减少初学者这种痛苦，本站暂停了JiveJdon2.5的下载）。
J2EE/Java EE的发展就是降低这种痛苦，首先想到的方式是：在Jsp调试上下苦功，要求Tomcat等服务器提供详细的错误定位；可惜到Tomcat 5.5我们也没看到这种功能；实际上，根本解决之道就是将Jsp的调试变成java组件的调试。
首先通过MVC模式规定Jsp只能等同于Html，不能包含Java代码，将Jsp和Java代码分离，可是这样分离之后，它们结合起来又麻烦了，所以，虽然你使用MVC模式，但是还是直接基于Jsp技术，带来的是开发效率的降低。
Struts框架解决了这个问题，通过ActionForm可以将Jsp和JavaBeans方便快速地结合起来，但是有人又抱怨Struts的ActionForm限制太死，与Jsp虽能对应，只能一个ActionForm一个表单对应，而不能任意组件JavaBeans都可以和Jsp任意字段对应，这时就出来了组件型框架JSF/Tapestry。
表现层框架Struts/Tapestry/JSF架构比较 业务逻辑层框架 可伸缩性 因为EJB标准的推出，业务组件层以前基本是EJB的天下，但是EJB功能实在太强大，它考虑了世界顶级大型系统需求，因此免不了显得很复杂，当初，基本上所有的大型企业高端都是选用J2EE，选用J2EE实际是选用EJB。EJB强调的高可伸缩性为大型企业日益发展提供最大的发展空间，不再因为企业快速发展导致整个企业系统结构都要发生根本变化,这是使用EJB的现实优势。 这种企业系统的可伸缩性不是因为EJB存在才显得重要，而是我们企业架构选择需要考量的基本因素。换句话说，无论我们使用EJB与否，这个问题都需要考虑:一台服务器不够用怎么办？如果这台服务器死机会对企业运营带来什么影响？如果每个星期这台服务器停机维护升级会不会对企业带来打击？我的企业系统是不是需要可靠的、几乎不当机的7x24运行？当企业系统面对大量外部访问用户时，一台服务器是否够用？多台服务器联动的需求是否涉及软件技术更换？
在这个现实因素考量后，如果觉得不是很重要，或者说将来一段时间内这些因素无所谓，那么可以不选用EJB了。
为什么有不选用EJB的理由？因为它复杂，学习起来比较困难，EJB帮助我们考虑企业中可能碰到的大部分问题，实际上，有的我们不需要，这也就是为什么说EJB是一个重量级解决方案所在。
与重量级相比的是轻量，业务组件层轻量级解决方案有Spring/HiveMidn/Jdon Framework等，轻量一词曾经因为EJB的出现而变得时髦，给人造成的感觉是：EJB花了老鼻子力气完成的那些功能，使用我轻量级解决方案可以轻而易举也能解决，举重若轻啊，其实这是一种误解。
当曾经以轻量自居的Spring将事务机制纳入自己怀抱中时，它也开始低调轻量了，实际是不轻不重了；当然如果它把分布式计算和事务再次加入时，天平砝码也会沉下去的。
初学者总是愿意使用简单的解决方案，学习使用方便，因此比较喜欢轻量级框架技术，这是正常的，但是在使用轻量级别框架之前必须明白：你的系统将来真的只需要一台服务器即可？你的项目完成期真的非常紧急？
如果只需要一台巨强服务器，就不必选择EJB，EJB是因分布式多服务器而生，对于单台服务器，缺乏本地透明性，也就是说：你无法透过EJB直接和本地JVM或文件系统等打交道，透明性也是衡量一个框架的重要指标。 当然，重量和轻量并不完全对立，EJB3就是为了简化J2EE的使用，使得EJB不只是擅长处理大型企业系统，中小型系统也使用很方便，这实际上也是EJB轻量化的一种努力。什么是Java EE 5？
所以，对于架构选择来说，根本前提是需要明白你的系统现在或将来一段时间（注意需要考虑将来一段时间，不能只看眼前）是中小型系统还是大型系统？
灵活性/定制性/透明性 当然这个答案有时我们自己也可能很难给出，那么我们还需要从其他角度来考量EJB和非EJB之选，例如笔者曾经经历一个大型实时娱乐平台社区系统，从规模上说肯定是大型系统，设计目标10万人在线，从这个角度非选用EJB不可！
但是，EJB因为还有事务机制，虽然应用程序可以选择失效EJB事务，但是EJB容器设计因为考虑了事务，所以在其内核上总是会显得臃肿，是一种累赘，这也是一种重量表示，不需要的东西存在肯定会影响效率，那么难道我不能根据我的需求，对EJB整体包括EJB容器进行可配置式的切割？也就是说，我上面这个案例只需要EJB的分布式计算功能，其他的功能我都拆除，只剩余我需要的功能能运行就可以了，轻装上阵。
可惜，这种任意切割，应需而定的目标在EJB3标准还没有被重视，所幸的是，Ioc/AOP技术为这种目标实现提供了实现可能，但是，只有Ioc/AOP还是不够，特别是看Ioc的范围，如果你只把应用系统组件纳入Ioc管理时，自由解耦只属于应用系统，我上面案例的目标还是无法达到，当你把框架本身组件也纳入Ioc管理时，任意切割，应需而定的目标才真正实现。
Spring和EJB3属于“只把应用系统组件纳入Ioc管理”，这从JBoss 4.0版本可以看出；那什么框架会把框架本身组件也纳入Ioc管理呢？Apache的Hivemind和笔者开发的Jdon框架。
什么样的组件可以被纳入Ioc管理呢？POJO组件，POJO这个概念其实当初是针对EJB缺点而推出，EJB要求应用系统的组件必须继承或依赖EJB容器，这样使得调试变的不方便，但是后来，POJO的概念已经不只最初这些概念，POJO代表那种与周围完全脱离关系、自由自在的Object了，如果应用系统的Model或者Service都是POJO，意味着你的应用系统不依赖任何其他系统，解耦性灵活性高。
POJO是因为EJB而提出的，当EJB自己倾向POJO时，大家都在宣称自己是POJO时，POJO概念就没有立足点了，这也是Java领域哭笑不得的现象，但是我个人更倾向把非EJB的JavaBeans组件通称为POJO。
Hivemind的Ioc依赖注射部分功能和Jdon框架非常类似，当上百个POJO组件配置时，完全不必指定它们之间的依赖关系；你可以将自己应用程序的组件注册到Registry中，这样Hivemind将帮助你启动这些组件，正如你在Jdon框架中将你的组件写入mycontainer.xml中，Jdon框架也将自动启动你这些组件，并解决它们之间的互相调用，包括和框架本身组件互动。
HiveMind和Jdon框架定义的POJO Service有如下特点： 不象EJB那样缺乏本地透明化(location transparency)概念，这些POJO Service总是能定位到同样一个JVM；也不象基于XML的Web服务web services那样没有语言透明(language transparency)概念，这些POJO Service总是可以被一组Java接口来概括替代(通过调用Java interface来替代调用这些具体Service)；当然，更不会类似JMX或Jini，不能进行service的热装载（ hot-loading）。
注意：当Ioc/AOP提供高度灵活的同时，已经有初学者开始抱怨Spring的过分灵活，那么比Spring在组件上更灵活的Jdon框架只能算是一种追求极端，它不一定构成你进行架构选择的主要依据！
上面这些讨论只是表明在灵活性（解耦性/透明性）这条需求道路上深究下去的选择，你自己的应用系统需求会产生各种不同的要求，有些要求甚至是极致的，这种偏向程度就成为你架构选择的目标，如果你的这种极致要求在目前Java世界里还没有可选框架时，那么你就要动手自己做了，这也说明什么时候你开始自己做框架（如Jdon框架），虽然在大多数情况下我们是不必要自己发明轮子的。