你能解释一下上下文设计模式吗? [英] Can you explain the Context design pattern?

问题描述

我已经开始阅读上下文设计模式.这是我从文字中了解到的:

I've started to read about the Context design pattern. Here's what I understood from the text :

• 你有一张包含所有变量的地图

• you have a map containing all your variables

你把它传递给任何需要它的人，这样你就不必将所有变量作为方法参数发送

you pass it around to whoever needs it, so that you won't have to send all the variables as method parameters

我明白"了吗?

推荐答案

我明白"了吗?

很抱歉，不完全是.

上下文对象的目标不是将大量参数隐式传递给方法，作为绕过强类型和封装的一种手段.目标是以通用但受管理的方式存储范围数据，独立于协议和表示技术.存储在范围内的数据本质上是共享的，仍然可以结构化，并且与传递给方法的一次性参数本质上不同.

The goal of Context Object is not to pass lots of parameters to methods implicitly, as a means of by-passing strong typing and encapsulation. The goal is to store scoped data in a general, but managed way, independent of protocols and presentation technology. Data stored within a scope is by nature shared, can still be structured, and is inherently different than one-off parameters passed to a method.

上下文对象模式首次在 Core J2EE Patterns 2nd 中引入埃德.上下文"部分指的是对象在 范围
的上下文中保存数据的事实(例如application/session/request/conversation/flash).

Context Object Pattern was first introduced in the Core J2EE Patterns 2nd Ed. The 'Context' part refers to the fact that the Object holds data in the Context of a scope
(such as application/session/request/conversation/flash).

其目的是尽可能地将应用程序数据和逻辑与协议/表示技术特定的类(例如HttpSession 和HttpRequest)分离.

Its purpose is to decouple, as much as possible, application data and logic from protocol/presentation-technology- specific classes such as HttpSession and HttpRequest.

模式实现

在上下文对象下，用于应用程序/会话/请求/其他范围的数据不会直接放入ServletContext/HttpSession/HttpRequest/其他特定于协议的类.相反，数据存储在 POJO 包装器类中，然后位于 ServletRequest/HttpSession/HttpRequest/other 中.

Under Context Object, data intended for application/session/request/other scope is not put directly into ServletContext/HttpSession/HttpRequest/other protocol-specific class. Instead, the data is stored in a POJO wrapper class, that then sits in the ServletRequest/HttpSession/HttpRequest/other.

上下文对象可以将数据存储在地图中，但它不需要 - 它可以以与程序相关的任何结构/格式存储数据.

The Context Object may store the data in a map, but it doesn't need to - it can store the data in any structure/format relevant to the program.

一个应用程序可以在每个范围内使用一个上下文对象类，也可以使用多个以有序方式拆分数据的类，避免类过度膨胀并促进关注点分离.

An application may use one Context Object class per scope, or several classes which split the data in an orderly fashion, avoiding excessive Class bloat and promoting separation of concerns.

上下文对象由最前面的表示类(视图、前端控制器、调度程序)使用.这些表示客户端对象调用 contextObject.get 来检索存储的范围数据和 contextObject.put 来存储范围上下文数据.

The Context Object is used by the frontmost presentation classes (Views, Front Controllers, Dispatchers). These presentation client objects call contextObject.get to retrieve stored scoped data and contextObject.put to store scoped context data.

它不会传递到业务/集成逻辑中.它不用作将大量参数传递到业务对象、绕过强类型的方法.业务层和集成层由使用特定强类型参数的业务代表、应用服务和/或会话 Facades 引领.

It is not passed into business/integration logic. It is not used as a means of passing a multitude of parameters into business objects, by-passing strong typing. The Business and Integration Tiers are fronted by Business Delegates, Application Services and/or Session Facades which use specific strongly-typed parameters.

模式优势

• 可测试性:单元测试只需要模拟一个简单的 POJO，而不是特定于协议的复杂服务器类，例如 ServletContext 或 HttpRequest
• 灵活性和可重用性:应用程序的核心独立于瘦协议特定的表示"层类.这意味着应用程序可以更轻松地更改或添加协议或表示技术(例如 HTML/HTTP/Servlet 和 WAP/Servlet 以及 XML/SOAP/HTTP/EJB 和 HTML/HTTP/JSF).

评论

• 是一种历史模式
• 有人可能会争辩说依赖注入框架，例如 CDI、Guice、Spring、Seam 和 &其他人提供已经以独立于协议的方式实现的范围存储.即所有范围都已经实现为上下文对象，这意味着开发人员不需要创建额外的上下文对象.这并不否定模式 - 这意味着 CDI 框架已经支持该模式.
• 如果实施不当，最终可能会出现在整个应用程序中传递巨大的上下文对象"反模式

引用 KaptajnKold:我想你明白了.但是，我也认为它更像是一种需要避免的反模式.在此处了解原因.

您的评论是指上下文对象的错误实现版本.上下文对象本身不是反模式.

Your comments refer to the misimplemented version of Context Object. Context Object itself is not an anti-pattern.

这篇关于你能解释一下上下文设计模式吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！