业务逻辑层

之前我们已经完成了服务层，因为当时展现层还没有出来，所以只做了简单介绍。传送门： 项目架构开发：服务层（上） 这次我们通过一个维护系统用户的场景来介绍一下服务层真正的设计用意。 1、新增用户场景 新增用户可能会有以下步骤 实现以上需求，开发人员一般情况下可能就是以上 蓝 红 黑 紫 绿 几种选择 1、有些写在Controllers、有些写在Application 2、都写在Controllers或都写在Application 3、有些写在DAL层、甚至存储过程 特别是新手以及那些拿来主义的人，他们不会花更多时间去思考。 分不清各层的职责以及界限，迷信那句： 不管黑猫白猫，抓到老鼠就是好猫 最后造成劣质的代码满天飞，到处（无论哪个公司或项目）都充斥着这种随心所欲的代码 分层已经失去意义，因为整个系统在局外人看来已经只有一层，那就是业务逻辑层，上至html、下至数据库存储过程 都充满业务逻辑。联想一下，这只是用户注册而已，还有更加复杂的业务场景还没说出来。不知道最后会怎样 这样的系统已经完完全全一团面条了，后续维护已经与个人技能无关了，就算请一线的NB程序员，想来他也只会说一句，去年买了个表 好了，吐槽了一下现状（不管你们同不同意，反正我是不会收回的，哈） 有没有方法解决上面这种窘境呢，当然是有的，比如我就觉得那种蓝色的方案勉强还可以 在UI层解决数据合法性校验，在逻辑层完成功能性问题

http://www.cnblogs.com/seaky/archive/2011/04/06/1982533.html 在深入分析MVC和MVP之前，我们有必要回顾下经典的三层架构。分层是计算机学科解决许多问题的法宝。在企业应用和互联网应用中，分层架构得到了非常广泛的应用。3层架构是各种层架构的基础，3层架构简单描述如下: 展示层 :展示层有两个职责 1负责展示业务数据 2提供用户输入的接口 业务逻辑层 :业务逻辑层的职责是接受展示层的输入，并经过业务处理逻辑，返回业务数据。 数据访问层 :数据访问层提供系统数据的存取服务。 从架构到实现是存在一些"距离"的，架构的实现是要基于应用场景，实现方案也有所不一样。 本文考虑两种应用场景来讨论MVC和MVP: 第一是c/s架构，也就是所谓的胖客户端，像RIA属于这类。Flex，ajax等技术都可以归结到RIA，手机APP，winform连接到远程服务的应用都可以归结这一类。 第二是b/s架构(某些web程序部分的利用了ajax，排除利用ajax的这部分)，也就是瘦客户端，b是指浏览器，在b/s架构中http协议是客户端和服务端通信的唯一协议，而且是通过浏览器来展示数据的。 基于层的架构的实现中的一个问题就是层与层之间如何通信，以及如何在层间传递数据。 首先看看数据访问层和业务层之间的通信和数据传递。 (注意， 数据访问层不保存持久数据

前言 记得几个月前，在一次北京博客园俱乐部的活动上，最后一个环节是话题自由讨论。就是提几个话题，然后大家各自加入感兴趣的话题小组，进行自由讨论。当时金色海洋同学提出了一个话题——“什么是业务逻辑”。当时我和大家讨论ASP.NET MVC的相关话题去了，就没能加入“业务逻辑”组的讨论，比较遗憾。 其实，一段时间内，我脑子里对“业务逻辑”的概念也是非常模糊的。但在不断地阅读、思考和实践过程中，这个概念及其相关的内容才在我脑子里渐渐清晰。我想，很多朋友也许也对这个概念不是很了解，所以愿意结合既有资料和自己的思考，总结一篇关于业务逻辑的概述性文章，一则与朋友们分享探讨，二则也是为自己对业务逻辑的学习做一个总结和提升。因为我还不敢说对业务逻辑内涵及外延理解的非常充分，所以文中如有不当之处，还请各位不用客气，尽管批评就好！ 内容提要 =================== 前篇===================== 前言 内容提要 1、我把业务逻辑丢了！——找回丢失的业务逻辑 2、细说业务逻辑 2.1、业务逻辑到底是什么 2.2、业务逻辑的组成结构 2.2.1、领域实体（Domain Entity） 2.2.2、业务规则（Business Rules） 2.2.3、完整性约束（Validation） 2.2.4、业务流程及工作流（Business Processes and

三层架构 ： 通常意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“ 高内聚低耦合 ”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。 顾名思义，三层架构分为三层，分别是“数据访问层”、“业务逻辑层”、“表示层”。 数据访问层：数据访问层在作业过程中访问数据系统中的文件，实现对数据库中数据的读取保存操作。 表示层：主要功能是显示数据和接受传输用户的数据，可以在为网站的系统运行提供交互式操作界面，表示层的应用方式比较常见，例如Windows窗体和Web页面。 业务逻辑层：将用户的输入信息进行甄别处理，分别保存。建立新的数据存储方式，在存储过程中对数据进行读取，将“商业逻辑”描述代码进行包含。 三层架构软件系统为用户的数据传输、提取、储存创造了便利条件。在应用数据时，信息划分架构开发项目，对各层次之间的工作职责进行清晰规划，这样就降低了网站系统的维护风险。 原理： 3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。 所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层

最近一段时间在研究petShop，希望能通过了解petShop的设计理念，整理出一套重用性强，适合自己在小项目中使用的架构。以作日后使用。 petshop4.0 详解之一（系统架构设计） 前言：PetShop是一个范例，微软用它来展示.Net企业系统开发的能力。业界有许多.Net与J2EE之争，许多数据是从微软的PetShop和Sun的PetStore而来。这种争论不可避免带有浓厚的商业色彩，对于我们开发人员而言，没有必要过多关注。然而PetShop随着版本的不断更新，至现在基于.Net 2.0的PetShop4.0为止，整个设计逐渐变得成熟而优雅，却又很多可以借鉴之处。PetShop是一个小型的项目，系统架构与代码都比较简单，却也凸现了许多颇有价值的设计与开发理念。本系列试图对PetShop作一个全方位的解剖，依据的代码是PetShop4.0，可以从链接http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdasamppet4.asp中获得。 一、PetShop的系统架构设计 在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或成为领域层）、表示层，如图所示： 图一：三层的分层式结构