药店系统

【今日推荐】：为什么一到面试就懵逼！>>> 介绍 上一篇我们讲述了《 AgileEAS.NET平台开发实例-药店系统-准备开发环境(上) 》将生成的解决方案进行相关配置。本篇我们将会开始讲述如下内容：如何基于现有的解决 方案来搭建一个可测试的运行环境，并且我们新建一个简单的例子，通过例子来说明我们如何来开发一个新的功能模块。 一、添加UI层 2、添加“BLL”层类库 添加好之后，我们就可以进行相关的后续工作了。 大纲 1、新建一个BLL层的业务逻辑服务 2、新建一个UI层模块 3、配置测试环境。 4、测试模块运行。 新建一个业务逻辑层服务 上面我们已经添加好了UI、BLL层工程，下面我们就来看看如何来属性业务逻辑层，首先，该层可以是分布式服务层与普通服务层的集成。这个怎么理解呢？下面我们来说 明下： 1、书写普通或者分布式业务逻辑，我们都要进行如下的格式来书写，否则如果之后想进行分布式的迁移，那么将无法通过配置文件来配置就可以完成无缝切换。 a、不使用AgileEAS.NET平台的普通的业务逻辑层： 我们这里添加了一个类“药品字典”实体，该业务逻辑返回所有的行，我们平时可能书写的方式就 是使用贫血模型，在业务逻辑层处理实体真正的业务逻辑，然后服务层完成实体数据的持久化。 b、使用AgileEAS.NET的业务逻辑层写法。 首先、添加如下几个程序集引用。 其次

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 开篇 我们知道我们正常的开发流程是从需求-设计-开发-测试-部署等这样的瀑布型的模式或者是瀑布模式的变种等，但是不管是如何的开发模式，前提是必须把需求确定才能从 需求中分析出要开发的用户的功能性需求和非功能性需求，这样我们才能进行后续的开发工作。那么我们本篇就将分析药店系统应该具有的功能及非功能性的需求，来得需求 分析文档的内容。 首先我们来看看一般的软件开发流程吧： 这是传统的软件开发流程，无非目前的不管是迭代开发、增量开发、敏捷开发无非都是基于传统开发模式的一些变种。 迭代开发是基于传统的软件开发流程之上的一种基于原型的迭代开发，开发完成后进行集成测试。 增量开发是将每个模块都走从设计-编码-测试的流程，最后完成集成测试。 敏捷开发是迭代开发+增量开发的合成体。 关于不同的开发模式及开发流程方面的内容，我们后面会详细的阐述，单独讲述AgileEAS.NET敏捷开发平台的软件工程思想的真实体现。 不管我们开发什么样的软件或者多小的软件，我们必须先了解需求，才能继续进行后续的需求分析及详细设计等后续的流程，所以我们知道了需求的重要性，那么我们本 篇就将药店系统的需求来分析和业务梳理下，整理成需求文档。 大纲 1、分析药店的业务流程 2、整理出每个功能的具体需求。 药店业务流程 下面我们就来分析下药店的业务流程

开篇 我们都知道开发一个软件必须要有开发的背景和特殊的需求等等，我们就来分析我们开发该系统的项目背景和开发该项目的目的。下面我们来分析下开发药店系统的目的 及可行性研究分析，对现有平台构建该项目的风险性等进行分析，可行性方案的分析。其他方面的因素分析。 大纲 1、总论 2、项目建设的背景和必要性 3、项目的方案设计 总论 我们既然要开发药店系统，那么我们必须知道开发这个项目的意义和目的，药店系统主要解决很多的药店的信息化管理，从采购到销售到财务管理等一体化的信息化系统 解决方案。该系统包含药品采购管理，药品库存管理，药店销售管理等子模块，药店信息管理软件针对我国医药企业药品经营管理特点（尤其是中小型药店销售商）而特别设 计，符合GSP管理规范，软件界面设计简洁，美观，其人性化的软件流程，使普通用户不需培训也能很快掌握软件操作使用方法，上手极易。药店信息管理软件广泛适用于医 药批发零售企业、药店、医院药房等用于药品进销存管理, 医药财务管理等场合，是您医药企业进行信息化管理的强大工具。 本药店系统结合AgileEAS.NET敏捷开发平台的完美实践，能够做到良好的扩展性和快速开发，我在现有的基础上通过1星期的时间完成了药店的所有功能，从需求-设计- 编码-测试等过程。可以充分体现AgileEAS.NET敏捷开发平台提供的工具的强大性。 项目建设的背景和必要性

介绍 前面的大量的篇幅已经讲述了，关于系统的配置及如何使用平台提供的相关开发工具来进行应用功能模块的开发，本篇将会开始讲述数据访问层中的相关设计与如何使用 AgileEAS.NET代码生成器生成的DAL层基础之上，进行相关的开发及开发过程中的一些限制。下面我们将会开始详细的阐述AgileEAS.NET平台中的关于DAL层的相关设计的 原理和思路，及相关的实现方案。 上面是给出ORM的一个模型图，AgileEAS.NET的ORM实现机制是通过数据模型来完成实体与数据库表的映射，当然可能大家可以理解为通过XML的模型来生成数据库 表与实体之间的映射关系。 但是其实AgileEAS.NET平台的真正的映射是通过特性+反射的形式来定义的： 通过特性+反射来定义数据库数据列与实体属性之间的关系映射，具体的特性定义如下： 1、表特性映射定义： 2、列映射定义： 3、我们看完了ORM之间映射是通过特性来完成的，下面我们来分析下每个实体的基类“DataEntity<T>”的相关定义和说明： 这样我们就分析完毕该基础实体类提供的相关持久化方法，那么我们在业务逻辑层或者UI层开发或者使用实体时我们就可以直接使用其中提供的方法，而不用我们自己去 书写，这极大的提高了我们的开发效率和速度，并且提高了可维护性等。 大纲 1、主要是讲述DAL层中的属性列的使用和定义说明 2、基于现有代码如何添加其他功能。 3

介绍 上篇我们分析了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来传输数据。 关于上述架构的组织

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

介绍 上一篇我们给出了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层或者服务 层，来直连数据库访问数据

开篇 上篇我们讲述了UI层的分析，那么本篇我们就讲述下我们在做CS应用程序的过程中的一些技巧性的东西，可能我这里总结的只是我再开发本药店系统中应用的到的一些小 技巧，并不代表全部，肯定还有很多的其他方面的技巧，大家都可以分享一下，我这里提出额也谈不上技巧，更多的是使用设计模式方面的总结吧。 1、提升父类 2、分离职责。 3、抽象公共 大纲 1、将每个子类都用到的方法或属性进行提升到基类中。 2、抽取公共方法。 提升父类 关于这个技巧我想大家都会是比较清楚的，就是将子类中都有的属性或者方法等放在一个基类中，然后具体的子类继承自该类，书写一些具有自身特性的功能，这样能够 充分发挥面向对象的继承技术来达到复用的目的，不但提高了程序的可维护性，而且提高了可读性。我想大家对这个都很熟悉。 下面我们就来看看我们在本药店系统是如何来做的： 上面我们能看到整个系统的核心就是基于药店的库存管理为主线进行具体的不同的业务流线来展开的，我们来总结下这些模块需要具备的功能，我们这里进行抽象。 这样，我们通过新建一个UserControl控件将这类控件都提供上述的功能。 2、这样我们在具体的窗体控件中只需要继承自该用户控件即可： 3、我们来看看基类中定义的打印报表方法的使用： 这样会减少我们很多不必要的工作，并且提高了可维护性，降低了重复代码的出现。 抽象控件绑定 今天有很多的同仁给我建议

开篇 上面我们讲述了，关于AgileEAS.NET环境的搭建，环境搭建好了，我们就可以进行相关的数据库原型设计了，平台提供了相关的数据库模型设计器工具，根据模型来生成 数据库创建表的脚本与ORM映射部分中的实体的相关代码，从而让我们在开发的过程中代码能够保持一致，并且不会出现一些因为笔误或者其他主观原因影响的代码难维护 性。 数据库原型设计器主要提供如下的几部分功能： 1、数据库建模,通过XML文件来保存，类似PowerDesign的设计思路，可以提供给不同的开发人员公用。 2、通过数据库模型-生成数据库建表脚本。 3、通过数据库模型-生成数据库设计文档。 4、通过数据库模型-生成解决方案-[仅包含ORM的映射实体信息]。 5、通过已有数据表-生成数据库模型。 可能通过文字还不够直观，还是老路，看图说话： 上面的图形已经描述了数据库设计器的基本功能，我们下面来结合着“药店系统”来讲述该工具的使用。 数据库建模-药店系统 上面给出了数据库设计工具的大体功能，下面我们来讲述如何使用该工具来进行数据库建模。 1、运行“Bin”目录下的“EAS.Develop.OrmDesigner.exe”应用程序： 2、点击上述程序后，显示如下画面： 3、点击左侧导航栏中的“实体”上点击右键： 4、我们先新建一个实体，出现如下界面，右侧的内容区将会提供相关的实体信息配置与编辑功能： 5