大话代码架构（项目实战版）.html.pdf

序言 2017年是不平凡的一年。 时隔4年，Nokia终于带着情怀回归了。 苹果也迎来了10周年纪念。 微信小程序对个人用户开放了。 2017年是一个非常强调“工匠精神”的一年，但是MOL（即笔者本人）在本书中强调的是“懒人精神”。不管你承认与否，所有的人都希望自己能不劳而获。当然，这只是一个美好的愿望。MOL只 能教大家做最少的事情来赚取更多的休息时间及陪伴家人的时间，这就是我所谓的“懒人精神”。 有些读者可能好奇为何笔者给自己起了MOL这个奇怪的笔名。关于这个问题，笔者在2014年出版的ASP.NET入门很简单一书中有过交代，有兴趣的读者可以去看看那本书。 凡属过往，皆为序章。 写ASP.NET入门很简单的时候，MOL刚刚结婚。在写本书的时候，MOL已经有了幸福的三口之家，宝宝已经可以通过一些简单的词汇来表达自己的情绪和意愿，并且还会跟MOL抢键盘。我的妻 也在为这个幸福之家努力奋斗。想想自己真是幸运。虽然本书写得艰苦，家庭工作琐事也繁多，但是为了自己的这份幸运和广大期待本书已久的“摩丝”（MOL的粉丝），即使再艰苦，MOL都没有放弃。 所谓更牛，只是换个“罪”受。 作为一个技术宅男，MOL更愿意每天只对着计算机写写代码就可以完成自己养家糊口的任务。理想总是那么丰满，而现实又是如此骨感。对于一个职业程序员来说，MOL的经历还算比较丰富。记得图 书市场上出版过一本不想当厨子的裁缝不是好司机，后来这个有点无厘头的书名成了一句经常被人引用的调侃语。在此MOL也想把这句话改改，和朋友们说“不想当程序员的艺术家不是好魔术师”。 非常幸运，这几种职业MOL都做过，也希望读者朋友们的职业经历丰富一些。 在我带领自己的技术团队做项目的时候，经历过痛苦，也经历过欢笑。我一直都觉得自己非常幸运，因为在本书中出现的刘朋、岳鹏辉、李冲冲他们3个人，悟性非常高，而且颇有自己的见解。在征得 他们的同意后，他们将以真实名字在本书中出现。 MOL不是大牛，只是愿意把自己的经历与更多的人分享。所以，本书中并没有讲解非常高、精、尖的技术，而是带领大家走进了“懒人”的世界。每个程序员都会进入迷茫期，不知道自己要干什么。 所以希望本书能从另一个也许大家从未思考过的角度给大家一些启发。 从你翻开本书的第一页开始，MOL相信你已经准备好换一种“受罪”的方式了，那你离“更牛”也就不远了！ 最后，MOL要响应习主席的号召，撸起袖子，加油干！对于MOL和大多数的“摩丝”来说，恐怕我们要脱掉秋裤，加油跑了！ 先给自己定一个小目标，今年，2017年，我要成为一个“懒人”！ 田伟 前言 架构（Architecture）是什么？可能每个人给出的答案都不同。业界流行一句笑话： Architecture is like teenage sex，everybody talks about it，nobody really knows what it is. 当然，MOL也不可能给出一个关于架构的准确定义。MOL更愿意把架构归为哲学的范畴。架构本身其实和软件开发并无太大关系。一个国家有自己的管理体系；一个公司有自己的组织架构；一个家庭 也有独特的男权或女权的特色，小到一个人；也是可以分为自我、本我和超我的。每个事物都是由一个个更小的事物组合而成的，而这些其实都与架构相关。 在宏观世界里，所有的国家公民构成了一个国家主体，国家主体对每个公民进行管理和约束，这是架构。 在微观世界里，电子绕着原子核高速转动，始终不会脱离原子核的管辖范围。而原子核和电子又组成一个原子。原子对电子、质子、中子的管理就是架构。 本书的读者一定是软件行业的高手或菜鸟，那我们就回到软件编程的世界里。 每个软件项目都是由代码和服务器构成的，如何统筹安排代码和服务器，就是架构的范畴了。 一个项目可能要使用多台服务器，如Web服务器、数据库服务器、文件服务器、CDN如何针对不同的要求对服务器进行选型，这是架构；如何统一管理这些服务器，这是架构；如何让这些服务器 平稳运行，这也是架构。 开发项目使用什么语言，是Java还是Node.js？选用什么数据库，是Oracle还是MongoDB？这是架构。 具体到开发过程中，某个模块应该如何安排，是交给DBA（数据库管理员）用存储过程来实现，还是让C#程序员访问数据库实现？这是架构。 在写C#代码的时候，采用三层架构，还是MVC？这是架构。 如何写日志，是使用I/O读写文件？还是采用log4net？或者是AOP切片写日志？这是架构。 甚至具体到某种技术的时候，也有架构。比如MOL规定项目要使用MVC架构，那么使用微软的MVC，还是Spring的MVC？这都是架构。 可见，架构涉及的范围非常之广。弱水三千，MOL只给一瓢。本书将从代码架构的角度来让大家一窥架构的真面目。 C#是一门非常优雅的编程语言（当然MOL并无编程语言的偏见），所以本书中所有的代码都以C#语言来描述。 本书特色 1.风趣幽默 MOL一直比较反对平铺直叙的讲解方式，所以本书的语言风格是比较幽默的。在本书的内容中将出现3个与MOL并肩作战的兄弟（公司老大邓总不在此列），以对话形式抛出问题并解决问题。 2.案例分析 本书中只有一个项目“晋商卡”，但MOL会带着大家见证“晋商卡”从无到有的过程，大家可以在这个过程中获得很多意想不到的收获。 3.向循规蹈矩说NO 正如MOL在结语中所说，2017年是一个强调“工匠精神”的一年。几乎所有的人都在精益求精地做自己的事情。但MOL要分享给大家的是一种懒人精神，我们不愿意日复一日地重复昨天的自己，我 们要站在更高的层面，做更少的事情，却有更多的收获。 本书内容及体系结构 第1篇 需求与三层架构（第13章） 本篇详细介绍了项目开发的前置节点需求，并对常见的三层架构给出了分析。在第1篇中提出了面向对象的重点概念，并让大家初步认识抽象的过程。 相信很多人一定被书中大段的SQL代码搞得云里雾里，不用担心，在第3章中MOL将带领大家完成懒人的第一步如何不写SQL代码。 第2篇 NoSQL和测试（第4、5章） NoSQL是现在比较流行的一个话题和技术。在第4章中将通过讲解MongoDB来介绍NoSQL如何使用，并且纠正大家的一个错误观念：NoSQL和ORM不能搭配使用。 第5章分享了测试的工作，并讲解了单元测试、黑盒测试、白盒测试让大家在收获的同时，也能理解测试工程师在工作中所要面临的一些痛苦。 第3篇 高精尖技术（第69章） 任何一个网站项目，似乎都绕不开“缓存”这个神奇的空间。缓存用得好，可以加快系统的反应速度。如果缓存用得不好，不仅用户体验差，还可能造成服务器宕机。第6章就分享了如何使用缓存。 每个程序员都有一个全栈的梦想，而前端又是全栈中必不可少的一部分，第7章讲解了如何使用EasyUI来搭建前端。 现在越来越多的电商网站都会做一些抢购或促销活动，当然这就使得网站不可避免地面临高并发。如何处理高并发呢？第8章将通过讲解消息队列，来说明如何应对高并发。 微信已经成了人们生活中必不可少的一部分。在2017年3月27日这一天，微信小程序也对个人用户开放了。我们如何把“晋商卡”挂到微信公众平台上，又如何开发微信小程序呢？这些问题都将在第9 章中解决。 本书读者对象 ·对代码架构感兴趣的初学者； ·对代码架构感兴趣的爱好者； ·高校学生和相关培训学校的学员； ·初入职场需要提高开发水平的开发人员。 因为书中所有的代码都以C#语言来描述，所以本书读者如果有一定的C#语言基础更佳。 本书配套资源及获取方式 为了方便读者高效地学习，本书特意提供了以下配套资源： ·本书源代码文件； ·本书涉及的一些开发工具的安装包。 这些配套资源需要读者自行下载。请读者登录机械工业出版社华章公司的网站www.hzbook.com，然后搜索到本书页面，按照页面上的说明进行下载。 本书作者 本书主要由田伟（就是笔者MOL）和郎小娇主笔编写。其他参与编写的人员还有李小妹、周晨、桂凤林等。 读者阅读本书时若有疑问，可以发邮件到hzbook2017163.com以获得帮助。 引言 我叫MOL，如果你是MOL的读者，那么一定知道“摩丝”了。MOL者，“摩尔”也。摩丝者，MOL的粉丝也。MOL在本书里将带领大家一起做一个属于自己的代码架构。 代码架构和架构是一样的吗？且看MOL如何分解。 一谈到架构（Architecture），大家一定会觉得它是一个非常“高大上”的东西，当然，大部分人都是这样宣传的。为了让大家有一个更好的感性认识（因为本书并不是讲架构的，所以只要有感性认 识就可以了），MOL决定用一个简单的例子来告诉大家什么是架构。 一个架构师的例子 在2015年的时候，MOL主导了一个B2C（Business-To-Customer，商家对客户）网站，MOL在这个项目里面充当了非常多的角色，如产品经理、项目经理、架构师、DBA（数据库管理员）、程序 员、QA（质量管理员）、Tester（测试员）现在来看一下MOL作为架构师时所做的事情。 MOL作为架构师，是以大体需求为前提的，也就是说，我们在这里不去讲如何获取需求，因为这不是架构师份内的事。当MOL拿到需求以后，就可以进行架构了。架构大体上分为两部分：硬架构和软 架构（这并不是标准的叫法，只是想让大家更好地理解架构）。 1.硬架构 顾名思义，硬架构就是关于硬件的架构。MOL根据目标用户量和业务要求，采购了3台服务器，分别作为文件服务器、数据库服务器和Web服务器（同时兼任缓存服务器），同时，建议用户在客户量 增加到一定数量级以后，增加CDN（Content Delivery Network，内容分发网络）服务器，以加快访问速度。 OK，架构师的输出已经完成了。但大家以为架构师就买几台服务器就完事儿了吗？那就大错特错了。在买服务器的背后，MOL对需求进行了研究，分析了网站需要承担的平均访问量和网站的业务内 容。这个网站的访问量并没有大到令人发指的地步，所以我们暂时不用考虑硬件负载均衡的问题，只需要提供一台Web服务器就可以了。这台Web服务器需要处理用户发来的请求并做出响应给用户。为了 提高Web服务器的性能，我们将会在这台Web服务器上安装虚拟机，并用Nginx（一个HTTP服务器，类似于IIS）做软负载均衡。 由于本系统中需要保存大量的用户文件，如果把这些文件都放在Web服务器上，那会给软件负载均衡产生额外的负担，并且大量的文件很容易把一台服务器“撑爆”。所以，我们用一台服务器专门来 保存文件信息，这台服务器就叫文件服务器。 数据库是一个项目中必不可少的一部分，数据库的本质其实就是文件和内容的组合，所以数据库的空间增长也是不可小觑的。而且数据库的操作，将会耗费大量宝贵的CPU和内存资源。所以我们将数 据库专门放在一台服务器上，这台服务器就叫数据库服务器。 好，硬件资源采购完成了，我们要把它们组合到一起。Web服务器向网络公开，让用户可以访问，而文件服务器和数据库服务器只在局域网中，并不对外公开，这样可以在一定程序上保证安全性，而 且也为客户节省了费用。Web服务器可以访问文件服务器和数据库服务器。 其实硬架构是非常复杂的，但本书不是主要讲硬架构，所以这里讲得非常简单，有兴趣的读者可以自行找“某度”或“某狗”进行搜索。 2.软架构 本系统将采用.NET平台下的C#语言进行开发，采用SQL Server数据库，使用微软的Cache缓存配合Redis来做。前台将以3种终端展示，分别是PC、手机、平板。所以前端将会使用HTML 5来做。 Android手机APP使用Java语言来开发，iOS平台上的APP暂时不做。 同样的，软架构也只是让大家看到了输出，并没有讲为什么这样做，因为这也不是本书的重点。 上面粗略地讲了一下什么是架构。下面来具体看一下代码架构。废话不多说，直接来看图1和图2。 图1 正常的代码架构 图2 不普通、非文艺的代码架构 图1是一个常见的代码架构，而图2可能是新手程序员最喜欢的“代码结构”。代码架构的目的是让不同的代码块去干不同的事，最后再把这些代码块整合在一起，组成一个项目。这是本书要讲的内 容。 可以看到，代码架构和软件架构基本上不属于同一个层次的元素。但不可否认的是，代码架构是一个程序员应该具备的技能，也是通往架构师的必经之路。 PS：各位读者可能对用户和客户这两个概念理解有误，这里统一一下，用户（User）是指使用系统的人，客户（Customer）是指要求我们做这个系统并且支付开发费用的人。 背景及人物介绍 本书中，我们将延续MOL活泼幽默的风格。为了剧情的需要，书中将会出现5位主人公。 MOL：姑且称之为老鸟吧，从事代码工作多年，在公司中主要负责项目管理和代码架构。 邓总：公司老大，身材消瘦如马云，有一双深邃的眼睛。虽然是公司的老大，但在本书中出现的次数并不多。 刘朋：新入职员工，因为名字中的“朋”字“占地”面积很大，所以大家一般都会把“朋”字分开来念，所以他有另一个名字“月月”，性格比较幽默。 岳鹏辉：新入职员工，长得比较帅气（已有女朋友）。 李冲冲：新入职员工，打得一手好乒乓球。 这几位主人公将会在本书中出现，他们可能是说相声的，可能是打酱油的，也可能是回家跪搓衣板的。但是他们更重要的作用是构造一个个生动的故事，在这些故事里面，大家可以看到一个真正的项 目是如何搭建的。 故事来源于生活，却不高于生活，这里的人是真实的，故事是真实的，当然，最重要的是，项目是真实的，知识也是真实的。MOL尽量用最接地气的语言，最平实的故事，来讲述一个个“高大上”的 知识和技术。 我们的目标 我们经常会听到这样的话：“加班不是目的，目的是不加班”。这样的话让人无比窝火，但又无比正确。我们还会听到这样的话：“我这样严厉地要求你，是为了让你成长得更快”。你有理由反驳 吗？其实，换一种方式，我们可以快乐地成长。这也是MOL带团队的宗旨，也是本书的目的。MOL要让你快乐地看完这本书，最后发出的感慨一定是：“代码架构其实挺简单！” 好了，我们要开始了！ 第1篇 需求与三层架构 ·第1章 故事从一个电商网站开始 ·第2章 为什么是三层 ·第3章 ORM实体关系映射 第1章 故事从一个电商网站开始 按照惯例，一本书的开始一般会介绍一些基础知识，如Java语法、XML结构等。相信很多读者都立志做一名“高大上”的Coder，但是一看这种开篇讲语法的书就先泄气了。为了不让大家泄气，我们 将使用一个电商网站项目来作为开篇。 说到项目，大家一定会想到某培训机构的机票管理系统、通讯录估计大家都要被这些标题党搞疯了。这些听起来很好听的系统，不一定有什么实用价值。但是我们要介绍的项目，是一个实打实的、 已上线的、微信上可查找的一个项目。如果各位摩丝在任何时候觉得学习有点累了，或者迷茫了，可以上微信搜索“川商卡”，这就是我们要讲的系统。MOL在做这个系统的时候，用到的技术并不多，像 缓存、消息队列等这些技术在项目中没有出现，但在本书中MOL也会讲到。MOL可以很负责任地说，当大家学完这本书后，可以毫不费力地给自己快速搭建一个“高大上”的代码框架。 下面的内容，将是一些非常杂乱的、与代码看似无关的基础知识，请大家耐心看完。 1.1 需求？需求！ 相信大家对一些翻译软件的使用已达到炉火纯青的地步了，如果把“需求”这个词输入翻译软件，会出来一大堆对应的英文单词。这里只挑两个容易混淆的单词来说，即Request和Demand。 通常出现需求的地方，一般都会用Demand来描述，但是偶尔也会看到Request。这两个单词都是需求的意思，有啥区别嘞？ Demand是必须要完成的，没有商量的余地。比如你的BOSS告诉你：我们的项目要加入某宝支付的功能。这就是Demand。虽然过两天BOSS有可能把这个功能“砍掉”，但是令行禁止，你还是必须 得把某宝支付的功能实现。 Request是锦上添花的功能。比如你的BOSS是一位单身宅男，他问你：在网站某个页面的右下角加入一个美女的图片，可以吗？这就是Request，它表示请求。也就是说，你不加这个图片，项目照样 运行。至于这个图片是否要加，那就看你的心情喽。 下面，我们来描述一下本书中的项目需求。 由于本书中的项目采用的是敏捷开发，所以开发过程中的文档特别少（关键文档是不可以省略的）。这里不可能列出所有的需求文档内容，因此将使用Brain Storm（头脑风暴）的方式来描述需求： ·这是一个电商网站； ·这是一个O2O电商网站； ·这个网站有登录注册功能； ·这个网站有商品展示功能； ·这个网站有订单功能； ·这个网站有支付功能； ·这个网站有积分功能。 OK，需求就是这么多。估计很多小伙伴都已经开始吐槽了吧：上面的描述也能算需求吗？MOL可以很负责地告诉你，是的，而且这是沟通4个小时后的成果，你相信吗？好了，先不吐槽需求发起人 了。上面的7个功能，就是我们这本书里要实现的需求。好像这也没什么难点啊。但如果你这样想就错了。至于哪里错了，MOL不会做直接回答，在后面的每个章节中，都会对这个问题进行回答，请大家 自行品悟。如果你想要了解详细的需求，那可能要失望了，因为MOL并不打算在这里描述一个完整的需求，而且这并不是实际开发中的情况。在敏捷开发的项目里，一般都是到开发的最后阶段，才能明白 客户想要的是什么东西。 这里引用一幅项目开发领域流传很广的漫画来说明，如图1-1所示。 图1-1 项目开发漫画 1.2 敏捷开发简介 前面提到了敏捷开发，听起来是一个非常“高大上”的名词。下面让我们来看一下敏捷开发的真面目。 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行 使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。（引自百度百科） 如果专业的解释看不太懂，没关系。我们用简单的语言来描述敏捷开发的过程。 小明想买一部手机，他告诉手机厂家：我想要一部手机，这部手机要好看、好用。 厂家收到需求以后，肯定是一头雾水，一定在想，我们做的每一部手机都非常好用呀，此时的心情是崩溃的。但是本着顾客是上帝的原则，厂家开始做这部好看且好用的手机。首先，他们把手机壳做 了出来，打电话把小明叫到工厂：小明，手机壳做好了，你看是否符合你的需求？ 小明看完以后，无非就两种回答，符合或不符合。如果符合，那么厂家将继续研发手机屏幕。如果不符合，那么将根据小明的需求继续修改。 又过了几天，厂家打电话：小明，屏幕做好了，你看是否符合你的需求？ 终于，在一个阳光明媚的下午，小明交完钱，拿到了自己心仪的手机，留下孤寂的厂家负责人在风中凌乱：就一个诺基亚1020，至于让我们这么费劲吗。 这就是一个敏捷开发的表现形式，它最明显的特点就是小迭代，每个小功能都去找客户确认，最后完成产品的同时，也就知道了客户的具体需求。 这样描述敏捷开发肯定是不全面的，我们的目的是不给出一个敏捷开发的准确定义，只是想让大家对敏捷开发有一个感性认识。 敏捷开发越来越多地被很多开发团体利用。它的好处就是开发周期短、与客户交流密切，一旦有问题出现，能很快做出响应。 在敏捷开发的团队里，逐渐地出现了一种人“全栈工程师”，这种人的优势在于：他们是无所不知的。你说前端，他能给你讲HTML 5和CSS 3；你说C#，他能和你探讨.NET框架；你说Java，他 能和你研究JVM；你说大数据，他还对Hadoop的理解有独到之处，仿佛是无所不能。相信很多摩丝都有一个“全栈梦”，加油！ 1.3 UI用户界面 UI（User Interface，用户界面），这是一个可大可小的概念。往小了说，它就是一个图形界面，如网页、桌面窗口、手机窗口只要是你看见的，都可以算是UI；往大了说，UI包括产品经理、用户 体验工程师、美工（静态切图PS）、前端（HTML、CSS）、前端交互（JavaScript、jQuery、EasyUI） 1.4 数据库 别问我数据库是什么。MOL说过，这本书里不讲基础知识。在这里讲的是如何去设计数据库。 MOL相信很多大学老师一定是这样教学的：设计数据库一定要先设计数据字典，这个字典看起来像这样，如表1-1所示。 表1-1 登录信息的数据字典 这个字典描述了一个用户登录信息表。设计好这个字典以后，再去数据库（SQLServerOracleMySQL）中去实现这个字典，实现的方法无非就是SQL语句create table，或者用图形化工具去设计 表。 大家有没有觉得这个字典设计得有点鸡肋？如果要改需求，比如加入注册时间这个字段，试问，你会先修改字典，然后再去修改数据库吗？如果需求更改得比较频繁，那么你一定会厌烦“数据字 典”这个东西的。 其实不然，数据字典是一个神器，只是你的打开方式不对。 第2章 为什么是三层 还记得在引言中提到的几位主人公吗？从这一章开始，他们就要粉墨登场了！ “三层架构”这个词一定是新手程序员经常听到的，大家听起来一定觉得它有点“高大上”的感觉，然后纷纷把自己的项目进行分层，以求变成三层。那么，三层架构到底是什么？为什么要分三层？ 我们慢慢说来。 2.1 MOL带兄弟们去吃饭 时维九月，岁属三秋，这是一个阳光明媚的金秋，MOL所在的公司又新招了三位同学，MOL总算不是孤军奋战了，于是MOL带大家去了楼下一家餐厅吃饭。吃饭不是目的，这是给大家上的第一堂 课。 到了餐厅以后，一个很水灵的妹子迎上前来，问道：“几位帅哥要饭吗？” MOL当时就不高兴了，回道：“你看我们长得像丐帮的吗？” 妹子脸一红：“我的意思是，各位想吃点什么？” 这时，月月搭腔了：“蒸羊羔、蒸熊掌、蒸鹿尾儿、烧花鸭、烧” 妹子赶紧打住：“哥哥，我得问一下厨房师傅，看看能不能做。” 不大一会儿，妹子出来了：“实在对不住，您几位刚才点的那些，我们这里都做不了，因为这里是西餐厅。” 月月：“那二尺长的龙虾有吗？” 妹子：“二尺长的没有，有二尺七的，要吗？” MOL一看不对劲，这是要把我吃到破产的节奏啊，赶紧说：“二尺长的龙虾都没有，那就来小龙虾吧。” 妹子：“小龙虾暂时没有，如果您可以等的话，等采购师傅回来了，就有了。” MOL：“可以等，不就几分钟嘛。” 妹子愤愤地下去了，月月也一脸不满意，MOL赶紧打圆场：“不就是龙虾嘛，大小都是龙虾，小怎么啦？小就不能满足你了？” 然后是等待吃饭 吃完饭回到公司，MOL招集大家开会。 MOL：“今天这顿饭不能白吃，它将开始我给你们的第一课三层架构。” 月月：“吃饭都能扯上架构，神了嘿。” 鹏辉：“今天的饭吃得确实有点意思，不过还能和程序扯上关系就有点意思了。” MOL：“我们刚才在餐厅吃饭的时候，总共有这么4个角色，分别是我们3个“饭桶”、服务员、大厨和采购师傅。” （下面都是MOL口述，将不再以引号来包含） 在程序员的世界里，这几个角色分别对应的关系是： ·我们3个“饭桶”对应用户，因为我们是花钱享受服务的。 ·服务员是UI（User Interface用户接口）层，她是要展示给用户，并且和用户进行交互的，而且她还要和大厨进行交互。 ·大厨是BLL（Business Logic Layer业务逻辑层），他的任务是把食材加工成美食，并交给服务员，所以他既要和采购师傅交互，又要和服务员交互。 ·采购师傅是DAL（Data Access Layer数据访问层），它的任务是把食材采购回来并交给大厨。 除此之外，还有一个隐形的角色是菜市场的大妈，她负责把菜卖给采购师傅。她对应我们软件系统中的数据库。当然，我们对大妈是不感兴趣的，所以这里先不说大妈的事。 OK，根据上面的描述，我们可以把一个餐厅里的工作分成3个部分，分别是服务员、大厨和采购师傅，他们之间的相互关系如图2-1所示。 图2-1 餐厅分工 大家有没有想过，如果我雇佣一个人，这个人既会炒菜又能采购，还会当服务员，那么这些角色不就不用分开了吗？ 非常好，我们假设有这样一个人存在，他既要当服务员与食客沟通，还要炒菜，还要去买菜，那么将会发生什么情况呢？ 这个人先要恭敬地问食客“您来点什么？”，然后再跑到厨房换上工作服开始炒菜，如果发现没菜了还得自己去买菜。我相信，即使有这样一个人存在，那么他也会累得够呛。而且他炒菜或者采购的 时候，是不能与其他的食客沟通的。最后他累得实在不行了，辞职走人了，老板就哭了，因为他一走，餐厅就没人干活了，餐厅也得关门。 所以，分开服务员、大厨、采购员这几个角色，有利于每个角色都专注于自己的职责任务，而且，即使有人搁挑子不干了，那也只需要找一个对应职责的工人来顶上就可以了，不至于让整个餐厅都变 得很被动。 好了，说完了餐厅的分工，再来说一下我们所关心的代码中的三层架构。 通常意义上来说，三层架构是UI、BLL、DAL这3层。这3层可以对应到餐厅中的3个角色来对比理解。UI层负责与用户交互，并将用户的请求交给BLL层处理；BLL层负责从UI层获取请求并将处理后的 数据交给UI层，同时它还向DAL层发送请求，并获取DAL层返回的数据；DAL层负责接收BLL层的请求，并进行数据处理然后返回给BLL层，在大多数情况下，DAL还需要从数据库中获取数据。它们之间的 关系如图2-2所示。 图2-2 程序中的三层结构 同样的，我们完全可以不使用三层结构就可以完成一个项目，这种代码结构最常见于新手程序员写的代码。这样的结构将会面临很大的风险，如果业务逻辑变动，那么将会出现“牵一发而动全身”的 现象，由此不得不对整个项目进行修改。所以，分层可以让专业的层（Layer）去做专业的事情，如果逻辑有变动，那么只需要修改相应的层就可以了。 PS：餐厅吃饭的例子非常经典，它将贯穿于本书中的章节，在后面的章节中经常会说到“如果餐厅中的大厨有个助手”，希望大家能立刻回想起MOL在这一节给大家讲的餐厅吃饭的例子。 2.2 动手写一个三层结构 说了这么多，都只是停留在概念的层次，接下来，我们要写一个简单的三层结构的框架。这个框架只需要实现一个功能：用户输入两个数，并选择运算方法，运算只包括+、*、/。程序通过计算， 将计算结果输出到用户界面上。 OK，需求已经非常明确了，就是要做一个简单的能进行加、减、乘、除运算的计算器。那么前端可以使用任何方式，比如控制台、WinForm、WebForm、MVC为了直观和简单，这里将采用 WebForm来做为前台界面。而BLL主要是将数据逻辑进行处理，并调用DAL层计算结果，将得到的结果返回给界面。DAL只需要提供数据就OK了。在本例中，不考虑边界异常（如太长的数字会溢出等情 况）。 首先需要把项目的框架搭建好。新建一个名为Mol.Calc的解决方案，并加入一个Web项目（Mol.Calc.Portal）和两个类库项目（Mol.Calc.Bll和Mol.Calc.Dal），如图2-3所示。 图2-3 三层代码框架 PS：项目的命名一定要规范，一般来说，项目命名都是“公司.项目.模块名”。MOL所使用的开发环境是Windows 7+Visual Studio 2015+SQL Server 2012。关于环境的配置这里不会多说，否则显得本书 很low，大家也会很不耐烦。 2.3 简说MVC 提到三层架构，很多人就会想到MVC（Model View Controller，模型-视图-控制器）模型。MVC的结构如图2-9所示。 图2-9 MVC模型示意图 图2-9描述了一个MVC框架处理用户请求的流程。 （1）用户发起请求，请求将被送给Controller。 （2）Controller去Model中取数据。 （3）Model返回数据给Controller。 （4）Controller将数据返回给View。 （5）View展示给用户。 如果这个流程让你觉得难以理解，不要担心，因为我们还没有开始写MVC的代码，所以我们无法理解用户请求为什么是到控制器（Controller）而不是到视图界面（View），最后返回的时候不通过控 制器返回，而通过视图来返回大家只需要对MVC有一个感性认识即可，知道每一部分是干什么用的就OK了。 2.4 向三层代码中加入面向对象 面向对象其实是一个非常宽泛的概念，宽泛到不足以用一个章节甚至是一本书来说明面向对象，但MOL将尽量在书中的例子中浸透面向对象的思维。 前面已经讲述了通常的三层代码结构，本节将在三层代码中加入面向对象的元素。这种面向对象的思想在本节中将体现在两个地方： ·数据库表的面向对象； ·将所有的SQL操作都放到一个类（SqlHelper）中。 2.5 小说代码管理 安抚一下冲冲受伤的心灵，MOL又开始借题发挥了。 MOL：亲爱的同学们，你们写代码的时候一定要经常用Ctrl+S命令保存一下代码，就算下一秒是世界末日，也要把你的劳动成果保存下来。 冲冲：有一次，我的计算机丢了，心疼死了。倒不是心疼计算机，而是心疼里面的好多学习资料。 鹏辉：得了吧，你是心疼你那好几百GB的“学习资料吧”。 刘朋：瞎说啥实话。你把这些资料备份到网盘上不就得了？ 冲冲：瞧你们一个个龌龌龊龊的样子，我的学习资料都是编程代码神马的。我还遇到一个问题，就是我在公司写的代码，如果要拿到家里看的话，就需要用U盘拷回家，或者用邮箱存储起来，这样拷 贝非常不方便，并且很容易有错拷、漏拷的现象，想想还是有点小纠结的。如果有一个软件，可以记录我每次修改的时间和修改的内容，那就非常happy了。 MOL：世界上不缺乏美，而是缺少发现美的眼睛。你刚才说的这种软件很多，MOL接下来给大家展示一下这些软件。 2.6 小结 本章主要讲述了简单的三层架构，进而讲到了MVC架构，并在代码中加入了面向对象的元素，最后提到了代码管理的一些软件，着重讲解了Git的使用。 正如我们在2.4节中提到的，“面向对象”是本书中的一条主线，希望大家能接受它，爱上它，并在你的代码中使用它。 第3章 ORM实体关系映射 冰河解冻，彩蝶纷飞，狗熊撒欢。柳絮飘舞，万物复苏，这是一个 正当MOL抒发感情到不能自已的时候，以刘朋为首的三人小分队又如鬼魅一般地冒了出来。正所谓来者不善，善者不来，MOL先气沉丹田，使了一个夜战八方藏刀式：“呔，来将所谓何事？” 刘朋：主帅莫慌，小的们有好东东要分享。 MOL理了一下三七分的毛寸发型：“我慌了吗？” MOL：言归正传，有何事分享？ 刘朋煞有介事地说：This way please。 鹏辉：说人话！ 刘朋：请上坐，待吾慢慢呈于您敬观。 MOL不慌不忙地坐在工位上，刘朋打开Visual Studio。一边点着鼠标一边解说：我们听完三层架构以后，做了一个简单图书查询系统，这是DAL层，负责访问数据库；这是BLL层，负责处理业务逻 辑，UI层用MVC写的。 MOL看着，脸上露出了欣慰的微笑。 刘朋：这个项目的功能非常简单，但是 中文就是如此的博大精深，一个“但是”足以让人从万丈高楼的楼顶跌落到无尽的深渊，这个“但是”把MOL的小心肝吓得扑通扑通的。 刘朋一脸坏笑，接着说道：但是，DAL层存在大量重复的SQL语句的片断，无法抽象出来，而且存在大量的硬编码，不利于代码的扩展。 MOL：吓死朕了，给我来杯82年的雪碧压压惊。 MOL喝了一口水之后，接着说道：我以为多大点事呢。以你们现在的水平，能把这个项目写完了，已经很了不起了，写完了还能自己进行分析，甚至还能提出代码扩展方面的见解，这大大超出了我的 预期。今天我就来带着你们去把SQL语句“扼杀在摇篮里”。 3.1 说说OCP开放封闭原则 我们都知道，数据要存放在数据库中，程序要操作数据，就要直接或间接地操作数据库，要操作数据库，就不可避免地要写大量的SQL语句。这些SQL语句可以满足很多初级程序员的虚荣心，看着这 些简单或复杂的SQL语句被程序运行以后就可以得到自己想要的数据，是不是很有成就感？但是，问题也就随之而来了。 当写一个SQL语句的时候，就注定了这条SQL语句只能满足一种业务场景或一种类型业务场景。当业务场景发生变化的时候，SQL语句也有可能发生变化。SQL语句的变化又可能引起DAL层的变化，进 而影响到BLL层。这样一系列的连锁反应，是我们不想看到的。 当不得不修改某些代码的时候，我们更希望这些修改的影响范围最小，尽量不要涉及其他的层（Layer）。设计模式（Design Pattern）中的开放封闭原则（OCP Open Closed Principle）的目的就是 要解决上面提到的问题。 开放封闭原则简称开闭原则，是设计模式中非常基础的一个原则，它的表述是：在软件开发过程中，代码应该对扩展是开放的，对修改是封闭的。也就是说如果你要新增功能，欢迎；如果要修改现有 的功能，对不起，此路不通。 那问题来了：如果业务有更改，就是要修改代码，怎么办？ 看来修改SQL是势在必行了。既然绕不过这个问题，那么就只能让修改SQL的影响范围变为最小。最起码，DAL的修改不要影响到BLL层。但是BLL层调用DAL层的时候，经常会这样写： dalClass dal=new dalClass(); /实例化一个dal 对象 这样的代码导致DAL的修改必然会影响到BLL层，我们通常把这种关联关系叫做“耦合”。那么怎么能让DAL不影响到BLL层呢？如何让DAL层和BLL层的耦合关系不要那么密切呢？甚至让BLL层根本不 知道DAL层的存在，就达到了让BLL层和DAL层没有耦合的目的，也叫“解耦”。 PS：计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。 这句话是计算机界中的格言，那我们就试着加一个“中间层”来解决上面提到的问题。 3.2 解耦第一步接口要上位 从本节开始，我们要开始慢慢地搭建自己的代码结构了，我们将要做一个类似“川商卡”的项目。MOL是山西人，所以把项目名称定为“晋商卡”。 3.3 解耦第二步工厂模式解决new的问题 刘朋：接口层就长这个样子啊，好像也没什么用嘛。 鹏辉：如果没有接口层的话，我们是这样定义的： CustomerDAL customerDAL=new CustomerDAL(); 有了接口层以后，我们的定义是这样的： IDAL customerDAL=new CUstomerDAL(); 在写法上的差别并不是太大，而且增加了接口层还会增加开发量。接口层的意义也就是在设计层面吧。 冲冲：你讲的接口层的目的是阻断BLL和DAL层之间的关联，但我们在写代码的时候还是会去new一个DAL对象，好像也没有达到目的啊。 MOL：你们提的问题，也是我们接下来要探讨的知识。其实，冲冲的疑问是比较关键的，只要把new的问题解决了，大家也就自然了解了接口层其实并不是鸡肋。 为了不使用new来实例化一个DAL，那么我们会考虑使用工厂模式来达到这个效果。 工厂模式算是一种比较常见的设计模式（Design Pattern），工厂模式的目的是不用new来创建一个实例。接下来用“演绎法”来描述一下工厂模式。 前面已经说过，加入接口层以后，实例化一个对象可能是这样： IDAL customerDAL=new CUstomerDAL(); 我们不想用new的方式来创建实例，而希望是这样： IDAL customerDAL=工厂.创建（实例类型）; 第一反应，就是把new的操作放到工厂中去执行。那么工厂就需要根据传入不同的实例类型来“制造”出不同的对象实例。最简单的方式是使用switchcase来输出对应的对象实例。例如： public static object GetInstences(string className) switch (className) case “userDal“: return new userDal(); case “orderDal“: return new orderDal(); case “pageDal“: return new pageDal(); case “customerDal“: return new customerDal(); default: return nu