我的问题很简单，我的目的是生成一个包含您的回复的存储库，以便在选择用于开发企业通用应用程序的框架时为社区服务。 这非常适用于通用语言，例如 C++、C# 或 Java。
【问题讨论】：
这确实是一个过于笼统的问题，特别是因为对框架这个词有很多解释，并且在框架的世界中，针对不同的任务有许多不同的种类。不过，我会为 Java 试一试。
Java 的默认整体企业框架称为 Java EE。 Java EE 非常强调分层架构。这是一个相当大的框架，学习它的各个方面可能需要一些时间。它支持多种类型的应用程序。极小极简单的可能只使用带有一些 scriptlet 的 JSP 文件，而较大的可能会使用更多。
Java EE 并没有真正强制您使用它的所有部分，但您可以选择自己喜欢的部分。
自上而下由以下部分组成：
对于 Web 层，Java EE 主要定义了一个名为 JSF - JavaServer Faces 的组件和基于 MVC 的 Web 框架。 JSF 使用一种称为 Facelets 的基于 XML 的视图描述语言（模板语言）。页面是通过定义模板并让模板客户端为其提供内容来创建的，包括其他 facelet，最后在其上放置组件和一般标记。
JSF 提供了一个定义明确的生命周期来完成每个 Web 应用程序应该做的所有事情：转换请求值、验证它们、调用业务逻辑（模型）并最终委托给（Facelets）视图进行渲染.
有关更详细的描述，请在此处查看 BalusC 的一些文章，例如What are the main disadvantages of Java Server Faces 2.0?
Java EE 框架中的业务层由称为EJB - Enterprise JavaBeans 的轻量级业务组件框架表示。 EJB 应该包含应用程序的纯业务逻辑。其中，EJB 负责处理事务、并发和需要时的远程处理。
一个普通的Java 类通过应用@Stateless 注解变成一个EJB。默认情况下，该 bean 的每个方法都是自动事务的。意思是，如果调用该方法并且没有事务处于活动状态，则启动一个，否则加入一个。如果需要，可以调整甚至禁用此行为。在大多数情况下，事务对程序员来说是透明的，但如果需要，Java EE 中有一个显式的 API 可以手动管理它们。这是JTA API - Java 事务 API。
使用@Asynchronous 注解可以轻松地使 EJB 上的方法异步执行。
Java EE 通过专门针对 EJB 的单独模块的概念明确支持分层。这隔离了这些 bean 并阻止它们访问它们的更高层。请参阅此Packaging EJB in JavaEE 6 WAR vs EAR 以获得更详细的解释。
对于持久性，Java EE 框架附带了一个名为 JPA - Java Persistence API 的标准 ORM 框架。这是基于使用@Entity 注释和@Id 对它们的属性或字段进行注释的普通java 类。可以选择（如果需要）通过注释指定对象和对象关系如何映射到关系数据库的更多信息。
JPA 非常强调纤细的实体。这意味着实体本身就是尽可能多的 POJO，可以轻松地发送到其他层甚至远程客户端。 Java EE 中的实体通常不关心自己的持久性（即，它不保存对 DB 连接等的任何引用）。相反，提供了一个名为 EntityManager 的单独类来处理实体。
使用此 EntityManager 最方便的方法是在 EJB bean 中，这使得获取实例和事务处理变得轻而易举。但是，在任何其他层中使用 JPA，甚至在框架之外（例如在 Java SE 中）也是受支持的。
这些是典型企业应用程序中与传统层相关的最重要的服务，但 Java EE 框架支持大量附加服务。其中一些是：
Java EE 框架通过JMS API - Java 消息传递服务直接支持消息传递。这允许业务代码将消息发送到所谓的队列和主题。应用程序的各个部分甚至远程应用程序都可以监听这样的队列或主题。
EJB 组件框架甚至有一种专门为消息传递而定制的 bean；消息驱动 bean，它有一个 onMessage 方法，当 bean 正在侦听的队列或主题的新消息进入时自动调用该方法。
除了 JMS，Java EE 还提供了event-bus，它是完整消息传递的简单轻量级替代方案。这是通过CDI API 提供的，这是一个全面的 API，其中包括为 Web 层提供范围并负责依赖注入。作为一个相当新的 API，它目前与 EJB 和 JSF 中的所谓托管 bean 部分重叠。
Java EE 提供了许多开箱即用的远程处理选项。只需让 EJB 实现远程接口，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 框架，这可能不会发生。
显然，一些人必须承担创建新框架的工作，否则行业只会停滞不前，但如果您最关心的是您的业务问题，我真的会三思而后行创建自己的框架.
【讨论】：
非常模糊的问题，我不确定在这一点上为工作项目“编写自己的”是否是一个好主意（除非编写自己的项目，否则就是项目）。如果这是一个学习练习，那很好，但否则请使用由长期从事此工作的人编写的库之一。如果您真的想参与其中，请阅读他们的代码，尝试贡献补丁等。
对于 .Net，有 Sharp Architecture 这是一个非常流行的分层应用程序框架。
这是我使用的一些东西（我不使用 Sharp Architecture）
首先，基础设施的东西
网页/用户界面
using 块用于呈现表单，但 System.Actions 用于呈现其他内容等）。再加上它不是真正的 OSS（你不能提交补丁）这一事实，对我来说，社区应该提出更好的 OSS 是一个令人信服的理由。坚持
服务/分销等
这些东西大部分是 OSS，所以它会存在多久，好吧，我想会很长一段时间。
【讨论】：
这个问题不太好。选择框架很困难，而且非常具体。对于每个选择过程，您最终可能会得到一个简单的候选名单和一个简单的要回答的问题列表，但这些列表并不能很好地转移到其他选择。
影响决策的参数数量和参数敏感性非常大，在企业层面很多都不是技术性的。
目前，没有框架可随时支持这些近期的企业需求：
【讨论】：