创建可扩展和抽象层

• 下载源代码 - 8.06 KB

引言

抽象和可扩展性是现代框架中的重要因素。如果您是任何框架团队的一员，或者正在开发一个将被您组织或社区的多个部门使用的库，您将体会到我所说的意思。

背景

我们不希望为特定用例开发一个可重用的框架库，然后发现该组件无法在其他场景中使用或不适合。在开发一个面向多个部门使用的框架/库时，会涉及许多挑战。我们应该构建应用程序在正常情况下用于满足其业务需求的功能。另一方面，我们不能强制要求他们使用我们已开发的开箱即用功能。关键在于，大多数团队应该能够将其用作开箱即用的功能。在需要时，由于动态/变化的业务需求，他们应该能够覆盖、扩展或将自己的功能插入框架。当需要覆盖默认功能时，我们不想更改端点——即接口。更改接口会导致破坏端点。

所以我们面临两个问题

1. 我们需要提供灵活性来更改我们的默认功能（开箱即用的功能）。
2. 同时，我们不想破坏接口，以免最终破坏现有代码。

本文概述了我们如何解决上述两个问题，同时提供一个健壮的可扩展和抽象层。

可扩展和抽象

可扩展框架允许消费者扩展提供的默认功能，同时又不破坏现有代码。抽象为消费者提供了一个不透明的层，他们不必关心另一端的具体实现，但仍能完成他们想要的任务。

逻辑架构

服务消费者

消费者是最终用户、外部应用程序或来自 Web 服务的请求等。消费者有兴趣访问服务。他们通过与服务外观（Service Façade）进行交互来实现这一目标。消费者将使用Request-Response对象与服务外观进行交互。

服务外观

服务外观是屏蔽消费者直接访问实际服务的层。该层充当入口点，并将消息路由到消费者想要调用的实际服务实现。服务路由器将拦截来自消费者的消息，根据Request将调用路由到实际服务。

服务

服务是细粒度的，执行任务、活动或业务逻辑等的实际逻辑。

类图

下图显示了解决方案的类图

ServiceFacade、各个服务都实现了IService接口，并使用Request、Response对象进行通信。这有助于ServiceFacade调用服务并完成工作。

优点和缺点

优点

以下是我所了解的这种方法的优点：

• 从服务提供商和消费者的角度来看，端点一致
• 可扩展，服务可以按原样使用，可以覆盖默认功能，并且可以在不影响外观和消费者的情况下插入新服务
• 抽象，消费者完全不知道服务外观、服务、服务执行等的内部实现。
• 能够在单个位置执行身份验证、授权逻辑
• 能够根据预先构建的逻辑、自定义逻辑等将消息路由到不同的服务
• 能够在单个位置执行追溯、仪器等横切关注点，而不是在所有服务和整个框架中
• 易于维护代码

缺点

以下是我所了解的这种方法的缺点：

• 随着时间的推移，服务外观可能会变得庞大，处理过多服务

关于示例程序

示例程序包含两个 C# 项目

• ExtensibleAbstractLayer - 类库项目
• ClientApp1 – 控制台客户端应用程序

工作原理

• 控制台客户端应用程序将命令行参数作为输入
• 将servicename和servicedata作为参数传递
• servicename应该是类（服务）的名称
• servicedata应该是服务期望的输入
• 当将“Base”作为servicename，将“1”作为servicedata传递时，将创建CustomerBase服务，并用“1”作为参数调用GetCustomerName()方法，结果将是“Robert”。

祝您编码愉快！

历史

• 2008 年 2 月 18 日：首次发布