中间件

介绍 上篇我们分析了AgileEAS.NET平台的DAL层的设计与相关的使用说明分析，本篇我们来分析下业务逻辑层/服务层的设计与分析，并且分析下如何抽离单独的业务逻辑 层，分离出单独的分布式访问服务支持。我们主要是分析如何设计出严格的基于现有DAL层之上的BLL->服务层>UI层这样的分层设计模式，本系列中的药店系统则采用的分层 方式是DAL->BLL层->UI层，下面我们来分析下这2种的不同的实现方案及代码的组织，并且分析关于分布式服务支持的写法和内部的实现原理分析。 大纲 1、DAL->BLL层->服务层->UI层。 2、DAL->BLL层->UI层。 3、AgileEAS.NET平台的分布式访问支持的契约分析。 DAL->BLL层->服务层->UI层 我们先来看看大家比较关系的将业务层与服务层职责相分类的实现方案。 通过上图我们知道这个分层架构中每层的职责，那么下面我们将会对每层的职责进行一个严格的划分和设计说明： 既然DAL层我们不添加任何的内容，那么我们把跟该实体相关的业务逻辑添加到BLL层,下面我们来看看。 有了相关的业务逻辑层我们就可以在服务层完成一些业务逻辑流程的组织：可以理解成服务层就是通过外观模式来控制业务逻辑流程的外观层。 综上所述，服务层就相当于一个业务逻辑流程的粗粒度的接口，当然我们在服务层与业务逻辑层之间通过DTO来传输数据。 关于上述架构的组织

可用的中间件 缓存中间件 class UpdateCacheMiddleware class FetchFromCacheMiddleware 开启全站范围的缓存。 如果开启了这些缓存，任何一个由Django提供的页面将会被缓存，缓存时长是由你在CACHE_MIDDLEWARE_SECONDS配置中定义的。 “通用”的中间件 class CommonMiddleware 给完美主义者增加一些便利条件： 禁止访问DISALLOWED_USER_AGENTS中设置的用户代理，这项配置应该是一个已编译的正则表达式对象的列表。 基于APPEND_SLASH和PREPEND_WWW的设置来重写URL。 如果APPEND_SLASH设为True，并且初始URL 没有以斜线结尾以及在URLconf 中没找到对应定义，这时形成一个斜线结尾的新URL。如果这个新的URL存在于URLconf，那么Django 重定向请求到这个新URL上。否则，按正常情况处理初始的URL。 比如，如果你没有为foo.com/bar定义有效的正则，但是 为 foo.com/bar/定义了有效的正则，foo.com/bar将会被重定向到foo.com/bar/。 如果PREPEND_WWW设为True，前面缺少 "www."的url将会被重定向到相同但是以一个"www."开头的url。 两种选项都是为了规范化url

开篇 在前面的章节中，我们说明了如何使用AgileEAS.NET敏捷开发平台俩开发药店系统，但是我们没有从总体上去说明AgileEAS.NET的一些功能，我们都是在细节上讲述了 一些该平台的相关特性，我们在药店系统的开发过程中，只是包含了该平台的大部分功能，还有一些功能，并没有使用到，可能我们后续会继续讲述这些功能。本文就将之前 开发的药店系统，来进行总结和综述吧，之前放出的文章中的配套文档相对来说，还有一些内容还需要完善，不过大体上已经很详尽了，本来想把概要设计文档也放出的，但 是我本机没有特别好的UML建模工具，所以就搁浅了，对大家说抱歉了。下面我们就来总结药店系统开发过程中的心得和体会。 大纲 1、AgileEAS.NET解决了药店系统开发中的哪些问题。 2、药店系统中用到了AgileEAS.NET平台中的哪些技术。 3、并且分析这些技术在其他领域的应用。 AgileEAS.NET平台解决的开发问题 我们在药店中遇到的问题，前面也有具体的文档有分析过，平台提供的功能也是比较强大，主要的功能图如下： 从上图中我们也可以发现，我们的非功能性方面的需求，例如药店系统，需要支持分布式访问支持等。包括一些部署等方面的要求等等。 1、打印问题： 我们的可选择： 水晶报表：微软提供的报表解决方案，功能强大，我认为使用该报表可以做出来一切报表，唯一缺点，需要客户机安装，否则无法使用。

开篇 上篇我们主要是讲述了《 WorkFlow设计篇Step.5—用户自定义工作流活动-WF4.0 》如何使用用户自定义活动来完成工作流的设计与开发，本篇我们将要开始讲述 设计篇的最后一章的内容，主要是讲述如何使用InvokeMethod的用法。 摘要 本篇我们是设计篇的最后一篇，本篇主要是讲述InvokeMethod的用法，一般来说有二种形式，一种是调用对象实例内的方法，一种是调用类型内部的方法，关于 具体的调用，我想大家也就基本了解了。 关于InvokeMethod的用法，我们本篇就会结合二种形式来说明。 关于InvokeMethod的二种不同的用法我们后面细细来说。 大纲 1、开篇 2、摘要 3、大纲 4、InvokeMethod活动的用法 InvokeMethod的用法 1、类型方法[静态方法] 1、新建一个控制台项目： 2、在现有项目上，添加一个静态类“TestMethod” class文件： 3、我们下载《 药店系统 》中的源码，使用其中的程序集： 4、修改静态类TestMethod内部的方法，代码如下： 5、修改项目中的配置文件的信息如下： 6、设计器视图内的工作流设计： 7、定义变量sequence上： 8、设置InvokeMethod活动上的属性： 9、下面我们就来设置相关的内容，我们来看看具体的其他的设置吧： a、选择targetType类型为静态类 b

开篇 上篇我们主要是讲述了《 WorkFlow设计篇Step.6—InvokeMethod调用对象或类型方法-WF4.0 》如何使用InvokeMethod完成工作流的设计与开发，本篇我们将要开始讲述 扩展篇的内容，主要是讲述如何使用集合Collection在工作流中的用法。 摘要 本篇我们是扩展篇的第一篇，本篇主要是讲述Collection的用法，一般来说我们对集合的操作，无非就是以下几种，增、删、查这几种，所以WF默认提供了一下四种 集合活动： 具体的作用，我想大家从字面上也能看出来个八九不离十，下面我们就具体的使用细节来说明下吧。 最后，我们来整理个流程，把这四类集合的活动，全部集成到一个流程中看看吧。 大纲 1、开篇 2、摘要 3、大纲 4、集合活动的用法 集合的用法 1、AddToCollection<T>活动 1、新建一个控制台项目： 2、将相应的节点添加到设计器中： 3、在顺序控制流中拖拽一个AddToCollection活动，选中该活动并查看相关属性，按F4 如下： 4、我们在sequence内定义一个变量，是集合类型的，比如Ilist，我们设置AddToCollection活动的相关属性： a、添加变量： 并且给MyCollection必须要初始化，否则会报错： b、设置AddToCollection活动的属性如下： 5、我们添加个foreach<T>活动

介绍 上一篇我们给出了AgileEAS.NET的关于Bll层的实现原理和Bll层的写法，我们可以在实际的开发过程中更深入的了解和实践，本篇我们就来讲述下UI层的实现原理和相关的 技巧，可能会和之前讲述的环境配置部分内容会有小部分的冲突吧，不过应该本篇讲述的更具有原理方面的内容，本文会讲述资源管理平台如何通过插件+平台的思路来实现这 种资源化的管理平台的原理和技术内幕。当然由于本人对AgileEAS.NET平台的理解的深度不足，或者说是认识上还有一定的偏差，可能会有错误之处，当然如果您有更深入的 了解，还请批评指正。 AgileEAS.NET平台采用的是平台+插件的设计思路，具体的UI层表示可以简单理解成如下图 通过上图我们知道符合插件契约的模块才能被资源管理平台识别，否则无法被资源管理平台识别和管理，也就无法享受容器提供的相关服务。 当然我们也可以不用AgileEAS.NET平台提供的资源管理工具，我们直接使用普通的Form窗体作为主窗体运行，也是可以的，不过AgileEAS.NET平台为我们提供了很多 底层模块的一些服务，例如组件的资源分配，动态释放对象，对象复活等，对象的生命周期等等。这些我们都要自己开发的过程中进行考虑。 下面我们来分析下如何新建一个新的应用程序来结合使用UI层，一种方式是自定义的不使用AgileEAS.NET平台提供的资源管理器

介绍 本篇将会讲述如何使用AgileEAS.NET敏捷开发平台来进行药店系统的开发，首先我们需要根据需求文档来设计出药店系统的系统架构，才能继续进行后续的开发工作，整 理好架构后，然后一步步的完成具体的详细设计，数据库建模等，这样的完整步骤后，就可以开展具体的编码工作了，我们首先来看看根据药店系统的一些功能性的需求和非 功能性的需求来决定系统的架构设计，并且分解AgileEAS.NET平台已提供的相关功能来结合分析。 分析 一、AgileEAS.NET平台的分层结构 1、基于AgileEAS.NET平台的逻辑架构设计分析 从上图我们可以看出，AgileEAS.NET开发平台之上的架构设计与我们平时说的架构设计中的分层与设计之上并没有什么本质的差别，唯独是底层的数据访问层(DAL)上的 设计有一些细微的差别，下面我们来画图分析下相关的区别。 AgileEAS.NET平台使用的模型是充血模型，意味着模型本身除了附带数据相关的信息外，还包含一些操作。 大家可以看看AgileEAS.NET平台中的DAL层就知道了，这里我就不贴出相关的代码了。 2、AgileEAS.NET平台的物理架构设计分析 上面给出了AgileEAS.NET平台的物理架构中的的分布式访问形式，当然还有简单的形式，即直接不通过分布式访问服务来访问数据库，而是直接UI层通过DAL层或者服务 层，来直连数据库访问数据

开篇 上一篇《 WorkFlow设计篇Step.4—异常处理(续)-WF4.0 》，我们讲述了工作流的异常处理活动用法，其实还有其他的方式，例如通过CodeActivity的引发等等，本 篇我们主要是讲述CodeActivity活动的使用，并且讲述如何使用CodeActivity。 摘要 WorkFlow是最近比较流行的一门技术，其实WF起源于20世纪70年代中期的办公化自动领域，自1993年8月，WFMC（工作流管理联盟）成立，1994年制定了一 系列的关于工作流的标准。进入21世纪工作流被越来越多的学者关注，该项技术越发走向成熟。当然我也是必须跟上时代的步伐，所以也加入工作流的大军，希望能 够跟上前人的脚步。当然也希望感兴趣的朋友，加入工作流的讨论群中来。具体群号： 120661978。 目前，我们已经在 AgileEAS.平台 中陆续集成了，界面设计器+工作流的内容，当然工作流目前还不算太成熟，还不方便放出来，本文只是抛砖引玉，还 希望 大家多多重视工作流的内容。 大纲 一、开篇 二、摘要 三、WF4.0的用户自定义活动 用户自定义活动CodeActivity 系统提供的活动节点，能够满足一些简单的流程，但是有些流程是我们自定义的活动组成的，这个时候，我们就可以通过系统提供的CodeActivity基类，我们重写 其中的属性和方法，来完成自定义的行为，进而完成我们自定义的流程

开篇 上篇我们主要是讲述了《 WorkFlow扩展篇Step.1—集合分组下的活动使用[上]-WF4.0 》如何使用集合Collection活动完成工作流的设计与开发，本篇我们将要继续 讲述集合活动内的另外二个活动的用法。 摘要 本篇我们是扩展篇的第二篇，本篇主要是讲述Collection的用法，一般来说我们对集合的操作，无非就是以下几种，增、删、查这几种，所以WF默认提供了一下四种 集合活动： 具体的作用，我想大家从字面上也能看出来个八九不离十，下面我们就具体的使用细节来说明下吧。 最后，我们来整理个流程，把这四类集合的活动，全部集成到一个流程中看看吧。 大纲 1、开篇 2、摘要 3、大纲 4、集合活动的用法[下] 集合的用法[下] 1、ExistsInCollection<T>活动 1、新建一个控制台项目： 2、将相应的节点添加到设计器中： 初始化变量信息： 3、参考上篇文章中关于AddToCollection<T>活动的设置，上面的活动设置完全相同，设置完毕后如下： 4、接着，在AddToCollection<T>活动下添加一个ExistsInCollection<T>活动： 5、下面我们来添加其他的WriteLine活动，来辅助我们测试输出结果： 6、F5，运行查看结果吧，看看是否结果与我们的预期相符： 上面我们就完成了ExistsInCollection<T>活动的说明

开篇 上一篇《 WorkFlow设计篇Step.2—传参的用法-订单金额的处理(续)-WF4.0 》，我们讲述了工作流的传入与传出参数的用法，其实还有其他的方式，例如通过Cod eActivity的In与Out参数等等，后面我们会进行说明的，本篇我们就会开始讲述工作流中的异常处理活动的用法，如何在工作流中处理tryCatch异常。 摘要 WorkFlow是最近比较流行的一门技术，其实WF起源于20世纪70年代中期的办公化自动领域，自1993年8月，WFMC（工作流管理联盟）成立，1994年制定了一 系列的关于工作流的标准。进入21世纪工作流被越来越多的学者关注，该项技术越发走向成熟。当然我也是必须跟上时代的步伐，所以也加入工作流的大军，希望能 够跟上前人的脚步。当然也希望感兴趣的朋友，加入工作流的讨论群中来。具体群号： 120661978。 目前，我们已经在 AgileEAS.平台 中陆续集成了，界面设计器+工作流的内容，当然工作流目前还不算太成熟，还不方便放出来，本文只是抛砖引玉，还 希望 大家多多重视工作流的内容。 大纲 一、开篇 二、摘要 三、WF4.0的异常处理 异常处理活动 异常处理是任何程序，都可能会发生的情况，那么我们在工作流中如何使用异常呢，下面我们就来看看如何使用工作流中提供的异常处理活动，包括我们有时 候想自定义异常处理的过程等，我们就来一一道来