Java的三大技术架构是什么？

2023-12-10 1501阅读

它是一套用于开发企业级环境应用程序的解决方案。该技术系统将采用Servlet、Jsp等技术，主要针对Web开发。主要用于普通桌面和商业应用开发，可以完成桌面应用的开发，如：Java版扫雷、Java版QQ等。例如，我们手机中的应用程序都是用Java语言编写的。Struts 支持大型 Java Web 项目的开发。Hibernate可以自动生成SQL语句并自动执行，让Java程序员可以随心所欲地使用对象。最具革命性的是，Hibernate可以在使用EJB的J2EE架构中取代CMP。从技术角度来看：软件架构随着技术创新不断更新其内容。模块化的目的是让软件能够分工。但目前还没有最优的实现技术。

什么是Java？ Java的三大技术架构是什么？

简单地说：Java是计算机数据和一系列指令的集合。

J2EE：企业级开发（目前称为JAVAEE）

它是一套用于开发企业级环境应用程序的解决方案。该技术系统将采用Servlet、Jsp等技术，主要针对Web开发。

J2SE：标准版本开发（目前称为JAVASE）

主要用于普通桌面和商业应用开发，可以完成桌面应用的开发，如：Java版扫雷、Java版QQ等。

J2ME：小版本（目前称为JAVAME）

它为电子消费产品提供解决方案。该系统主要应用于小型电子消费产品。例如，我们手机中的应用程序都是用Java语言编写的。

Java的三大框架是：

1、Structs框架是最早的Java开源框架之一。 Struts 是MVC 设计模式的优秀实现。

Struts是最早的Java开源框架之一，也是MVC设计模式的优秀实现。 Struts定义了通用的Controller，通过配置文件（通常是Struts-config.xml）隔离Model和View，并以Action的概念封装用户请求，使得代码更加清晰易读。 Struts 还提供了简化编码的工具，例如自动将请求的数据填充到对象和页面标记中。 Struts 支持大型 Java Web 项目的开发。

2、Struts2以WebWork优秀的设计思想为核心，吸收了Struts框架的一些优点，提供了一个通过MVC设计模式实现的更加整洁的Web应用框架。

Struts2以WebWork优秀的设计思想为核心，吸收了Struts框架的一些优点，提供了一个以MVC设计模式实现的更加整洁的Web应用框架。 Struts 2 引入了几个新的框架功能：将横切关注点与逻辑分离的拦截器、减少或消除配置文件、整个框架的强大表达语言以及基于 MVC 模式的可更改和可重用标签的支持。 API方面，Struts2充分利用了其他MVC框架的经验和教训，使得Struts2框架更加清晰、更加灵活。

3.Hibernate是一个开源的对象关系映射框架

它用非常轻量级的对象封装了 JDBC。它建立POJO和数据库表之间的映射关系。它是一个全自动的ORM框架。 Hibernate可以自动生成SQL语句并自动执行，让Java程序员可以随心所欲地使用对象。编程思维来操作数据库。 Hibernate 可以用于任何使用 JDBC 的情况。它可以用在Java客户端程序或Servlet/JSP Web应用程序中。最具革命性的是，Hibernate可以在使用EJB的J2EE架构中取代CMP。，完成数据持久化的重要任务。

软件架构作为一个概念体现在技术和业务两个方面。

从技术角度来看：软件架构随着技术创新不断更新其内容。软件架构基于当前技术和一些基本原则。

我们先来说一些基本原则：

分层原则：分层是用于降低软件深层复杂性的关键思想。就像社会有阶级一样，软件也有等级结构。

模块化原则：模块化是解决软件广度和复杂性的必然手段。模块化的目的是让软件能够分工。

接口实现分离原则随着软件模块化程度的不断提高，用面向接口的编程代替面向实现的编程可以让日益复杂的软件降低模块之间的耦合度，从而使各个模块更容易改进。从这个原则出发，软件也从微观角度进行了精心的标准化。

有两个较小但重要的原则：

细节隐藏原理显然将复杂问题简单化，隐藏了丑陋的细节，可以让软件结构更加清晰。事实上，这个原理很常用。 Java/C++语言中的封装原则和设计模式中的Facade（外观）模式都可以很好地体现这一原则的精神。

依赖倒置原则随着软件结构的进一步发展，层与模块之间的依赖关系逐渐加深，层与模块的动态可插拔性要求不合理地增加。依赖倒置原则可以看作是接口实现分离原则的深化。根据这一原则的精神，软件已经进入了工具时代。这个原则有点类似于著名的好莱坞规则：不要打电话给我们，我们会打电话给你。

上述原则确立了我们软件架构的价值指标。但软件架构毕竟是建立在现有技术之上的。每一代技术都有架构模式。我们不要再谈论过去了。我们来看看目前流行的技术以及目前我们可以采用的架构。

因为面向对象是目前最流行的开发技术，而设计模式的大量使用使得面向对象变得成熟，而数据库是目前最有效的存储结构，而Web界面是目前最流行的用户界面，所以目前最典型的三层架构是基于上述技术，采用数据库作为存储层，面向对象实现业务层，web作为用户界面层。我们先从三层架构开始：

由于面向对象技术和数据库技术不兼容，我们在标准三层架构的基础上增加了数据持久层来管理OR双向映射。但目前还没有最优的实现技术。 cmp 和实体 bean 技术由于其复杂的实现和有限的功能前景而处于被淘汰的边缘。 JDO和hibernate是OR映射的后来者，尤其是hibernate，功能相当齐全。推荐作为持久层首选

在业务层，因为现在的业务越来越过载，变化也频繁，所以我们必须有足够敏捷的技术来保证我们适应变化的能力。在标准的j2ee系统中，会话bean负责业务处理，性能良好，但ejb系统的使用改变了业务架构模型太多，复杂且昂贵，业务代码可移植性差。 Spring作为bean配置和漂亮的IOC模式实现的轻量级架构，对业务架构影响不大，所以推荐作为中间层业务框架。

在用户结构层，servlet/jsp/jstl/javaBean虽然可以实现MVC架构，但毕竟过于粗糙。 Struts对MVC架构的实现是比较完善的。 Taperstry也很好地实现了MVC架构，采用了基于事件的方式，这是非常有吸引力的。不幸的是，它还不够成熟。我们仍然推荐struts作为用户界面层基础设施。

因为业务层是三层架构中最具决定性的，所以让我们回到业务层来详细分析一下。在复杂的业务中，我们往往需要以下一项或多项基础服务：事务一致性服务acid（工具：jta/jts）、并发锁服务concurrent&&lock、池管理服务cache、访问控制服务（工具：jaas）、流程控制服务工作流、动态实现服务IOC、序列化消息服务（工具：jms）、负载均衡Service blance等。如果不使用重量级应用服务器（如weblogic、websphere、jboss等）和重量级组件（EJB），我们必须自己实施其中一些服务。虽然大多数情况下我们并不需要所有这些服务，但实现它们并不容易。幸运的是，我们有大量的开源实现代码，但采用开源代码往往不是一件容易的事。

随着xml作为结构化信息的传输和存储变得越来越重要，一些xml文档操作工具（DOM、Digester、SAX等）的使用也变得越来越重要，并且随着xml schema的java绑定工具的发展（jaxb、xmlbean等）成熟，使用xml schema设计xml文档格式，然后使用java绑定生成java beans将成为主要的编程模式，而这将进一步将数据中心转向xml，使得xquery更加更有可能用于中小型数据量。 XML 数据库的查询语言。最近还有另一个趋势。微软、IBM等开发了大量的中间软件如（Microsoft Office的InfoPath），可以直接从XML schema生成入口页面等非常实用的功能。而Web服务的广泛应用将对软件架构产生非常重大的影响。至于面向服务架构（SOA）的前景以及三层架构何时进入历史，目前还很难确定。

aop的发展也将对软件架构产生深远的影响。然而在面向对象的架构中，无论是aspectJ还是jboss-aop还是aspectWerks和nanning都有自己严重的问题：可维护性很差，所以会很困难。很难走远。也许作为一个好主意，它将被用在网络服务中。

作为W3C语义模型的标志性语言，很难想象rdf和owl会对当前的业务架构产生多大的影响。但如果它做到了它声称的那样，它就会广泛地改变信息的结构。它还将对软件架构产生深远的影响。

关于建筑设计的一些建议：

尝试构建一个完整的持久对象层。可以获得高回报

尝试对每个功能进行分层和块化，每个模块都依赖于其他模块的假定外观。

不能依赖静态数据来实现IOC模式。您应该依赖数据功能接口。静态数据只是实现数据特征接口的方式之一。

在设计架构时，是支持而不是依赖xml。但是，可以提供单个 xml 版本实现。

从业务角度来看：软件架构应该是深刻体现业务内部规则的业务架构。但由于业务变化频繁，软件架构很难保持不变。但业务的频繁变化不应该是由于软件架构的大规模、频繁的变化而导致的。原因是，软件架构应该是一个基于变更的架构。

一个企业能够稳定存在一段时间，是有它的理由的（暂且不说）。企业中有许多用例。每个用例都有固定的规则。每个规则都有一些可以判断的项目。每个项目一切都可以从某个维度来衡量。我们的架构必须首先确保它完美适应每种测量方法。许多失败的架构是由许多项目的测量方法的微小变化造成的。

每个用例都有规则。当我们分析业务用例时，我们经常假设某些规则是先验的且稳定的。然而，随后的业务变化往往证明这种观点是错误的。然而，我们的架构通常已经适应了它。付出了无法挽回的代价。大量事实证明，规则的改变往往是用例改变的根本原因。因此，我们的架构应该尽可能地适应规则的变化，尽可能地建立规则模板。

每个用例都与不同的角色相关联。每个用例的产生必然是由于角色的变化（注意：不是替换，而是增强或弱化），因此关注角色的各种可能情况对于架构的设计具有重要意义。在我们当前的三层架构中，角色与接口概念完美对应。

系统中的许多用例都是相互关联的。考虑到每个用例可能有不同的特殊情况，架构设计时应尽可能采用依赖倒置的原则。如果架构允许，可以使用消息传递模型（JMS）。这减少了耦合。

现在我们来谈谈业务稳定性存在理由对业务的影响。存在是合理的，这在这里当然是正确的。业务因人而存在，因此询问业务存在的原因意味着询问不同的角色为什么他们需要这个业务以及为什么他们喜欢或不喜欢当前的业务用例。所有这些角色都应该在系统中保留。 “待续”

架构设计需要考虑几个原则：

应尽可能分解用例

用例应该尽可能抽象

角色应尽可能独立

测量独立性原则

追求简单

这里不提供相关示例，后续更新中会提供示例。

业务与模式的关系

业务中的一些用例之间的关系往往与一些常规模式非常相似。但随着时间的发展，它逐渐与之前的模式产生了分歧。这是正常现象。不过，这对系统架构的要求非常高，要求系统架构能够适应部分机型的更新换代。在这里，我们尽早注意到用例之间的相互角色变化，为架构更新做好准备。

俗话说，你写的代码6个月后将是别人的代码......回顾！审查！审查！

软件工程的一般开发流程：愿景分析、业务建模、需求分析、鲁棒性设计、关键设计、最终设计、实现……

序列图也称为序列图（交互图）。它们属于软件工程的第二步——业务建模阶段的图表。业务建模要求我们把视角从系统转向组织，站在客户的角度看问题。为了清晰准确地“知敌”，术语就是从组织的角度来定位系统的价值，从而避免软件项目的失败，因为大量的软件项目失败都有着相同的特点。原因——最终的实现与用户需求不一致！因此，业务建模也称为组织建模。切记在业务建模和需求分析阶段忘记自己技术专家的身份！其实有很多话要说，就一句话：业务建模就是把系统放到组织里。

•组织——为了实现既定目标，按照一定的规则和程序设置多级岗位，其权责角色结构具有相应的人员隶属关系。如政府、企业等。

•商业——组织在该行业的工作。例如医院的医疗、急救等；银行的储蓄和贷款等

•业务建模[Business Modeling]——以软件模型的形式描述企业管理和业务中涉及的对象和元素，以及它们的属性、行为和关系。包括业务组织建模、业务流程建模、业务流程改进等。

业务建模的第一步是找到组织，然后明确组织的现状（必要时需要改进现状）。阐明当前情况一般需要以下两张图：业务用例图、业务序列图（或活动图、或文字）。从外部来看，组织是价值的集合，用业务用例图建模。业务用例图帮助我们从高层理解组织的业务结构。在内部，组织是系统的集合（人是一个智能系统），用业务序列图建模。业务序列图帮助我们详细了解组织的业务流程。每个业务用例代表一个业务流程。该过程通常使用文本、活动图或序列图来描述。

使用序列图描述业务的优点：从面向对象的角度看待业务流程。虽然活动图通常仅表示事件，但序列图可以表示职责和操作！

业务序列图的组成部分：业务执行者、业务工作者、业务实体，以及三者之间的交互来完成某个业务用例的实现过程。业务人员 [业务人员] - 位于业务组织内、负责业务流程中某些任务的人员。比如银行柜员、诊所的医生。业务实体——业务人员在业务用例实现过程中使用的“系统”。例如银行的点钞机、学校的校园一卡通系统。企业主体和企业从业人员可以相互代替各自的职责。

使用序列图描述业务状态的步骤：

1、识别业务对象：业务执行者、业务工作者、业务实体；

2.确定业务对象之间的职责、协作和交互顺序

3. 绘制业务时序图。

绘制图时，生命线是一条垂直的虚线，用于表示序列图中对象在一段时间内的存在情况。

举例：比如为某招聘公司进行业务建模——画出当前业务情况的时序图，并描述招聘的业务用例：该招聘公司在xxx市人才交流中心前台，要求发布招聘信息并向员工出示公司资格证书。后，工作人员将验证资格的有效性，招聘公司将招聘简介提供给工作人员。工作人员在招聘记录簿上填写公司招聘职位、招聘条件、公司简介等信息，并要求招聘公司核实。招聘公司核实无误后，工作人员将用彩纸将招聘信息张贴在招聘信息栏中，工作人员向招聘公司收取费用。（注：在实际工作中，类似上述的信息只有在分析师与组织的业务专家深入沟通后才能获得）。本例中的业务对象是招聘公司（业务执行者）和员工（业务人员）。找到业务对象后，我们开始确定每个对象之间的职责和交互......