【.NET深呼吸】应用上下文(AppContext)

在.net 4.6中新增了一个类,叫AppContext,这个家伙嘛,技术含量不算高,只不过是在编程的时候可以方便用用而已。应用上下文允许定义一个标识(用字符串表示),并且在应用程序运行期间可以切换状态。相当于一个开关,有两个状态——true or false。

实际上我们自己也可以实现这样的类,就是用一个static的字典来存储存,key是开关标识,value是bool值。不过,要是.net库里带了这个东西,那就方便很多,至少我们也不用自己去实现。

AppContext类的所有成员都是静态的,可见我上面的推断不假。调用SetSwitch方法可以设置一个开关标识,以及标识的状态。然后,在代码的其他地方可以用TryGetSwitch方法来检索某个开关标识的状态。如果状态打开,就执行A代码,如果状态关闭,就执行B代码,如果状态标识不存在,就执行C代码。

这会让我想到条件编译,这个应用上下文,真的和条件编译有着相似的地方,就是设定一个全局的标识符,然后在代码各处可以进行标识符的判断。但是,又跟条件编译有所区别。条件编译是某一部分代码不参与编译的,一旦改了条件就要重新编译。而AppContext是在代码本身完成的,所有代码会参与编译,只是在运行阶段进行判断。

举个例子,假如我有个K程序,然后为K定义一个叫color的上下文标识。点击窗口上的按钮后,代码会检测这个color标识,如要标识处于打开状态,就把椭圆填充为红色;如果标识是关闭状态,就把椭圆填充为灰色。

请看下面XAML:

    <StackPanel Margin="12">
        <CheckBox Content="应用上下文开关" Margin="3,9" Checked="OnChecked" Unchecked="OnUnchecked" />
        <Button Margin="10,5" Content="填充椭圆" Click="OnClick" />
        <Ellipse Width="160" Height="90" Name="elp" Stroke="Black" StrokeThickness="2" />
    </StackPanel>

咱们就用CheckBox来选择应用上下文标识是否开启。

以下是CheckBox的事件代码:

        private void OnChecked(object sender, RoutedEventArgs e)
        {
            AppContext.SetSwitch("color", true);
        }

        private void OnUnchecked(object sender, RoutedEventArgs e)
        {
            AppContext.SetSwitch("color", false);
        }

以上代码仅负责设置App Context的标识状态。

下面代码处理Button的事件:

        private void OnClick(object sender, RoutedEventArgs e)
        {
            bool b;
            if (AppContext.TryGetSwitch("color", out b))
            {
                _mBrush.Color = b ? Colors.Red : Colors.Gray;
            }
            else
            {
                _mBrush.Color = Colors.Transparent;
            }
        }

用TryGetSwitch方法可以获取某个标识的状态,状态值存放在out参数中;如果某个标识不存在(未设置),整个方法会返回false。注意,TryGetSwitch方法的返回值不是标识的状态值,请看方法原型:

static bool TryGetSwitch(string switchName, out bool isEnabled);

方法的返回值只是表明开关状态能否获取成功,而开关的状态是由isEnabled参数来存放的,参数方向是out。

运行后的结果如下图所示。

     

最后,还得跟大伙说一声,中秋节别吃太多月饼,三高食品。

时间: 2024-12-14 18:46:10

【.NET深呼吸】应用上下文(AppContext)的相关文章

flask基础之AppContext应用上下文和RequestContext请求上下文(六)

前言 应用上下文和请求上下文存在的目的,官方文档讲的很清楚,可参考: http://www.pythondoc.com/flask/appcontext.html 应用上下文对象在没有请求的时候是可以单独存在的,但是请求上下文对象只有在收到请求后才会被创建.请求处理和应用上下文和请求上下文的关系是: 接收请求-->创建请求上下文-->请求上下文入栈-->创建该请求的应用上下文-->应用上下文入栈-->处理逻辑-->请求上下文出栈-->应用上下文出栈 系列文章 fl

Android应用程序窗体设计框架介绍

在Android系统中,一个Activity相应一个应用程序窗体.不论什么一个Activity的启动都是由AMS服务和应用程序进程相互配合来完毕的.AMS服务统一调度系统中全部进程的Activity启动,而每一个Activity的启动过程则由其所属进程来完毕.AMS服务通过realStartActivityLocked函数来通知应用程序进程启动某个Activity: frameworks\base\services\java\com\android\server\am\ ActivityStac

Android应用程序窗口设计框架介绍

在Android系统中,一个Activity对应一个应用程序窗口,任何一个Activity的启动都是由AMS服务和应用程序进程相互配合来完成的.AMS服务统一调度系统中所有进程的Activity启动,而每个Activity的启动过程则由其所属进程来完成.AMS服务通过realStartActivityLocked函数来通知应用程序进程启动某个Activity: frameworks\base\services\java\com\android\server\am\ ActivityStack.j

Hadoop2.6.0运行mapreduce之推断(speculative)执行(一)

前言 当一个应用向YARN集群提交作业后,此作业的多个任务由于负载不均衡.资源分布不均等原因都会导致各个任务运行完成的时间不一致,甚至会出现一个任务明显慢于同一作业的其它任务的情况.如果对这种情况不加优化,最慢的任务最终会拖慢整个作业的整体执行进度.好在mapreduce框架提供了任务推断执行机制,当有必要时就启动一个备份任务.最终会采用备份任务和原任务中率先执行完的结果作为最终结果. 由于具体分析推断执行机制,篇幅很长,所以我会分成几篇内容陆续介绍. 推断执行测试 本文在我自己搭建的集群(集群

Oracle 11g数据库详解(2015-1-18更新)

Oracle 11g数据库详解 整理者:高压锅 QQ:280604597 Email:[email protected] 大家有什么不明白的地方,或者想要详细了解的地方可以联系我,我会认真回复的 1   简介 数据库操作主要有以下几步: 1.  启动.停止数据库 2.  连接.断开数据库 3.  创建.修改.删除数据库用户 4.  表空间 5.  新建.修改.删除表 6.  查询.插入.修改.删除表数据 7.  新建.修改.删除视图 8.  新建.修改.删除存储过程 9.  新建.修改.删除触发

【.NET深呼吸】基于异步上下文的本地变量(AsyncLocal)

在开始吹牛之前,老周说两个故事. 第一个故事是关于最近某些别有用心的人攻击.net的事,其实我们不用管它们,只要咱们知道自己是.net爱好者就行了,咱们就是因为热爱.net才会选择它.这些人在这段时间攻击.net,估计和.net的开源.跨平台有关,并且,据说VS 2015 Update 1会进一步深化和扩展全平台,估计有些人是沉不住气了,毕竟他们用的开发工具是比VS落后了四个多世纪的.最近又出了个Visual Studio Dev Essentials计划. 所以嘛,对于这些人,我把林妹妹的一首

flask快速入门笔记三_上下文对象:Flask核心机制

首先声明:内容大部分来自huizhiwang,只是单纯记笔记. 1 请求 :WSGI WSGI,全称 Web Server Gateway Interface,或者 Python Web Server Gateway Interface ,是为 Python 语言定义的Web服务器和Web应用程序之间的一种简单而通用的接口. WSGI将Web服务分成两个部分:服务器和应用程序.WGSI服务器只负责与网络相关的两件事:接收浏览器的 HTTP请求.向浏览器发送HTTP应答:而对HTTP请求的具体处理

Asp.net 面向接口框架之应用程序上下文作用域组件

在团队中推广面向接口开发两年左右,成果总体来说我还是挺满意的,使用面向接口开发的模块使用Unity容器配置的功能非常稳定也很好扩展. 但是由于当时开发的匆忙(边开发边应用),留下一些比较致命的问题: 1.很多接口定义的不合理,通用性和扩展性不好 2.固定死了使用Unity容器,如果更大面积推广有问题,有些人已经很熟悉其他容器了,再来重新学Unity没有必要 3.配置比较麻烦,需要简化 所以我觉得有必要重新开发一个框架,对原框架取其精华去其糟粕,再吸收开源项目(含微软开放源代码的部分),争取做出一

Android应用程序窗口(Activity)的运行上下文环境(Context)的创建过程分析

文章转载至CSDN社区罗升阳的安卓之旅,原文地址:http://blog.csdn.net/luoshengyang/article/details/8201936 在前文中,我们简要介绍了Android应用程序窗口的框架.Android应用程序窗口在运行的过程中,需要访问一些特定的资源或者类.这些特定的资源或者类构成了Android应用程序的运行上下文环境,Android应用程序窗口可以通过一个Context接口来访问它,这个Context接口也是我们在开发应用程序时经常碰到的.在本文中,我们