0

我们公司希望在 .net 堆栈上对整个企业的应用程序进行标准化。我们正在构建企业风格指南。我们有一位解决方案架构师帮助我们设计企业架构。他的建议包括企业服务层和具有可重用组件的企业 UI 层。

我完全同意拥有一个企业服务层,大多数(如果不是所有)网络应用程序都将使用它来获取数据。但是,我不相信企业 UI 层。

我们现有的许多应用程序都显示相同的信息,例如订单详细信息。他的论点是,我们公司已经花钱为每个应用程序多次构建订单详细信息 UI,而它显示已构建一次并在其他应用程序中重用。他希望在 angular 和 bootstrap 上构建可重用的 UI 组件,这些组件可以放入未来在同一堆栈上构建或重写的应用程序中。

我喜欢拥有可重用组件的想法,但我认为它应该仅限于结构和样式,而不包括 UI 框架。添加 UI 框架会增加每个控件的复杂性,而且成本也会更高,我们实际上是在构建一个 cms。除此之外,我觉得我们会被 angular 锁定,这不一定是坏事,但是如果像 react 这样的另一个框架更适合未来的应用程序呢?

我的问题是 -
1. 是否有人在具有类似架构的环境中构建或工作?你的经历是什么?
2. 您认为这种架构的优缺点是什么?

在此先感谢您的帮助。

4

2 回答 2

0

关于提供的建议:-

  1. 企业服务层:当然这是必要的,您可以统一和标准化您与后端系统、数据层和第 3 方系统的接口方式。这就是我们通常所说的企业服务总线“ESB”
  2. UI 集成与 UI 可重用性不同。您可以通过多种方式使用 UI 集成

    2.1 一些框架可以为您提供工具和 API,将多个 UI 组件“屏幕”从正在运行的应用程序集中到一个屏幕中。为此, Microsoft 有一个框架和一个商业产品。

    2.2 Java Portals 等一些技术允许您将“可重用 UI 组件及其业务逻辑”包含在任何其他门户页面中,并提供 API 以在 Portlet 之间进行通信。

  3. 可重用的 UI组件当然是显而易见的,但这是对架构没有真正影响的开发实践。它有自己的开销和治理,取决于您的项目规模。如果您有一个 UI 团队来服务所有项目,这可能会有效地确保具有高可重用性。

使用 ESB 绝对是最好的前进方式,但它会改变您习惯的方式。有一些地方需要考虑

  1. 应用程序映射到流程,根据发现重新设计应用程序
  2. 保护企业服务层并开发角色库访问控制。
  3. 查看您的运营工作簿,确保在拥有企业服务层后,您可以识别问题、隔离问题并减少对使用该服务层的其他系统的影响。
  4. 服务层中的一个错误或故障将影响所有系统,因此您必须提高质量并使用“如果您还没有”一些方法来提高质量,例如具有完全测试自动化的持续集成 (CI)。
  5. 您需要检查硬件并进行容量规划,以确保企业服务层运行良好并且可以扩展至足以支持所有应用程序。这里的性能测试将非常有用。企业架构师的主要任务之一是调整所有应用程序的大小,并为企业服务层环境推荐规范。
于 2016-03-28T11:20:30.590 回答
0

虽然有点晚了,但我希望提供一些指导,以便阅读本文的人能够从企业 IT 生态系统中获得最新信息。

建议/建议,

  1. 找出您组织的企业架构原则
  2. 例如,如果它说重用和回收,请在您的架构设计中选择可重用性。
  3. 如果它促进创新,请摆脱 UI 框架标准化,因为如今,Web、桌面、移动、平板电脑和设备等多模式应用程序消耗的每个应用程序/服务。
  4. 因此,专注于构建服务层,重新表述这一层,您将其称为 SOA/API 层,使用 RPC、REST 模式开发服务,让您的投资组合/业务开发团队发布 API/服务。编目它。
  5. 因此,谁想在任何 UI 框架中进行开发,就让他们进行试验,最终确定在一两个 UI 框架中。
  6. 正如 Ahmed Hashim 所指出的,如果您需要发布/订阅事件和编排,以及在您的生态系统中交换数据的大量业务线应用程序,请务必投资 ESB。
于 2021-10-21T06:18:34.927 回答