ArB*_*rBR 8 architecture frameworks
我的问题非常简单,我的目的是生成一个包含您的响应的存储库,以便在选择用于开发企业通用应用程序的框架时可以为社区服务.这非常适用于C++,C#或Java等通用语言.
Arj*_*jms 24
这确实是一个过于普遍的问题,特别是因为对框架这个词有很多解释,并且在框架的世界中,对于不同的任务有许多不同的解释.不过,我会试一试Java.
Java的默认整体企业框架称为Java EE.Java EE强调分层架构.这是一个非常大的框架,学习它的每个方面可能需要一些时间.它支持几种类型的应用程序.非常小而简单的可能只使用带有一些scriptlet的JSP文件,而较大的那些可能会使用更多.
Java EE并没有真正强制您使用它的所有部分,但您可以选择自己喜欢的内容.
自上而下它由以下部分组成:
对于Web层,Java EE主要定义一个组件和基于MVC的Web框架,称为JSFJavaServer Faces.JSF使用名为Facelets的基于XML的视图描述语言(模板语言).通过定义模板并让模板客户端为它们提供内容(包括其他facelets)并最终在其上放置组件和常规标记来创建页面.
JSF提供了一个定义良好的生命周期,用于完成每个Web应用程序应该执行的所有操作:转换请求值,验证它们,调用业务逻辑(模型)以及最终委派给(Facelets)视图进行渲染.
有关更详细的描述,请查看BalusC的一些文章,例如Java Server Faces 2.0的主要缺点是什么？
Java EE框架中的业务层由称为EJBEnterprise JavaBeans 的轻量级业务组件框架表示.EJB应该包含应用程序的纯业务逻辑.其中EJB负责处理事务,并发以及何时需要远程处理.
通过应用@Stateless注释,普通Java类成为EJB.默认情况下,该bean的每个方法都是自动事务性的.意思是,如果调用该方法并且没有事务处于活动状态,则启动一个,否则加入一个.如果需要,可以调整甚至禁用此行为.在大多数情况下,事务对程序员来说是透明的,但如果需要,Java EE中有一个显式API来手动管理它们.这是JTAAPI - Java Transaction API.
可以使用@Asynchronous批注轻松地使EJB上的方法执行异步.
Java EE通过专门针对EJB的单独模块的概念显式支持分层.这会隔离这些bean并阻止它们访问更高层.有关更详细的说明,请参阅JavaEE 6 WAR vs EAR中的此打包EJB.
对于持久性,Java EE框架附带了一个名为JPAJava Persistence API 的标准ORM框架.这是基于使用@Entity注释和带有@Id的属性或字段来注释普通java类.可选地(如果需要)可以通过关于对象和对象关系如何映射到关系数据库的注释来指定进一步的信息.
JPA非常重视苗条的实体.这意味着实体本身尽可能多的POJO可以轻松发送到其他层甚至远程客户端.Java EE中的实体通常不会处理自己的持久性(即它不包含对DB连接的任何引用等).相反,提供了一个单独的类EntityManager来处理实体.
使用此EntityManager最方便的方法是从EJB bean中获取,这使得获取实例和处理事务变得轻而易举.但是,在任何其他层中使用JPA,甚至支持框架之外(例如在Java SE中).
这些是与典型企业应用程序中的传统层相关的最重要的服务,但Java EE框架支持许多其他服务.其中一些是:
通过JMSAPI - Java Messaging Service 在Java EE框架中直接支持消息传递.这允许业务代码将消息发送到所谓的队列和主题.应用程序的各个部分甚至远程应用程序都可以监听这样的队列或主题.
EJB组件框架甚至有一种专门为消息传递定制的bean类型; 消息驱动的bean,它有一个onMessage方法,当bean正在侦听的队列或主题的新消息进入时会自动调用该方法.
除了JMS之外,Java EE还提供了event-bus一个简单,轻量级替代全面消息传递的方法.这是通过CDIAPI 提供的,API是一个综合的API,其中包括Web层的范围,并负责依赖注入.作为一个相当新的API,它目前与EJB和JSF的所谓托管bean部分重叠.
Java EE提供了许多用于远程开箱即用的选项.EJB可以通过外部代码公开,只需让它们实现远程接口即可通过二进制协议进行通信.
如果二进制通信不是一个选项,Java EE还提供各种Web服务实现.这是通过其他JAX-WS(Web服务,SOAP)和JAX-RS(Rest)完成的.
为了安排定期或定时作业,Java EE提供了一个简单的计时器API.此API支持使用自然语言的类似CRON的计时器,以及延迟执行代码或后续检查的计时器.
Java EE的这一部分是可用的,但正如所提到的那样相当基础.
Java EE中有相当多的东西,但我认为这涵盖了最重要的事情.
另一个Java的企业框架是Spring.这是一个专有的,但完全开源的框架.
正如Java EE框架一样,Spring框架包含一个Web框架(称为Spring MVC),一个业务组件框架(简称为Spring或Core Spring Framework)和一个Web服务堆栈(称为Spring Web Services).
虽然Java EE框架的许多部分可以单独使用,但Spring比Java EE更重视构建自己的堆栈.
Java EE与Spring的选择通常是受宗教影响的.从技术上讲,这两个框架都提供了类似的编程模型和相当数量的功能.Java EE可能被视为略微轻量级(强调约定优于配置)并具有类型安全注入的好处,而Spring可能提供更多开发人员经常需要的更小的便利方法.
另外,Spring提供了一个更全面且可直接使用的安全API(称为Spring Security),其中Java EE为(第三方)供应商提供了大量安全细节.
具体回答第二个问题：
开发你自己的框架会给你带来维护它和教育新开发人员使用它的负担。
您的框架越大，您必须专门投入的时间就越多，因此您解决实际业务问题的时间就越少。如果您的业务问题是框架，这是可以的，但否则它可能会成为一个问题，即使对于可以将一群人专门用于此类框架的非常大的公司也是如此。
如果您是一家较小的公司（比如最多 15 名开发人员），这真的会成为一个巨大的负担。
此外，如果您自己的框架是可以利用第三方开发的那种框架（例如第三方可以为 JSF 开发组件），那么您自己的框架显然无法利用这一点。
当然，除非你开源自己的框架，但这只会显着增加支持它的负担。仅将源代码转储到 sourceforge 上并不算数。你将不得不积极支持它。突然之间，您的框架变成了他们的框架，可能会有“奇怪的”功能请求和针对您没有个人兴趣的环境的尴尬错误报告。
这还假设您的框架实际上将由外部用户使用。除非它真的非常非常好并且你投入了大量精力，否则如果它只是无数的 Java web 或 ORM 框架，这可能不会发生。
显然，有些人必须承担创建新框架的工作，否则这个行业就会停滞不前，但如果您最关心的是您的业务问题，我真的会三思而后行，开始自己的框架。