我们活在当前，一个前所未有的时代，一个面向彼此的环境！
最近一段时间一直在学习各种框架知识，前端的后端的，现在来总结一下个人的感觉和心得！
校务管理系统:
如果我们现在开始接手一下:"校务管理系统",那么我们需要做什么呢？
1.考虑问题 ：
①:我们需要管理那些（校务人员、学生、教学环境、图书馆、教务系统、。。。）
②:也就是说我们一个校务管理系统可能要包括多个子系统，
2.OK，现在想通之后我们继续开发，首先选择了我们熟悉的学生管理作为第一个系统，开始系统原型界面、数据库模型的设计
开发中。。。
开发一段时间之后，我们发现我们的进展很慢，怎么办呢？开个碰头会吧，大家一起讨论讨论：
唧唧。。咋咋。。。
会议室内吵成一锅粥，原型应该这么设计。。。，你这么设计谁看得懂啊 ，要我说，界面应该美观，大气，你大气给谁看啊，那些教授都40多岁了，漂亮有什么用？
问题出来了：
①：由于我们没有良好的沟通交流已经分工，现在大家对于原型界面、系统规范、以及业务调用都处于混乱状态
②：由于我们同一个系统使用的人群不一样，可能界面需求需要变更
ok，了解之后，身为组长的我决定，小芳，你是美术出身，你来设计前端，小王，你是计算机出身你来做后台，其次数据库每一个表 字段都需要写注释，后台代码也一样
一个页面对用一个后台，
开发中。。。
开发一段时间之后，出现如下情况，王哥，我这个页面怎么出问题了？出不来了报错了，哦！是什么页面，就是排寝那个地方，哦，我在改动代码，你等会啊，那行吧，你快点儿，我刚刚改动了样式，需要看看效果，然后小芳去倒了杯奶茶，等着后台修改完成之后才能继续运行界面（这就是我们传统的WebForm窗体开发），后台和前端关联太紧密了
怎么办呢？集思广益吧，再开个碰头会。。。
现在我们开发的进度又满了下来大家说说都有什么问题：
①：东西太多太杂了，谁知道啊image文件夹里面居然放了JS文件，我的天啊
②：还有前后台太紧密了，人家想改东西都改不了
。。。
OK，了解问题之后我们去解决这个问题，首先是资源管理的问题，我们要求将所有的资源文件放入Content文件夹中,引用的第三方文件存放入指定的 ThirdParty文件夹中按名称存放，其次是关于前后台紧密的问题，我们采用将后台文件当前封装在类库中，然后在编译阶段指定编译的路径，这样我们后台改动如果不重新编译生成BLL的话，前端界面也就不会收到影响，因为在之前的BLL已经存在对应的后台代码
好的，现在我们来整理一下我们现在的系统，比较简洁的主程序入口，因为我们将资源文件（Content）、第三方插件（ThirdParty）、前端页面（WebUI）都按照功能存放在对应的文件夹中,其次后台代码封装在一个类库中，同样按照不同的功能模块封装在了各自的文件夹中，看起来很整齐哦
好吧，那我们再开个朋友会鼓励鼓励大家 :
① : 王哥，你怎么了，耷拉着个脑袋，哎别提了，新来的小赵对我们业务不熟悉，非的我一把手的交，做东西找目录啊什么的慢死了、
② : 小芳，那你呢 ？哎 别提了，最近数据量比较大，调整样式啊时候需要等半天数据才出来
。。。
ok，继续来总结一下问题，新来的员工对于系统上手速度慢，显得系统过于冗余，其次，数据的增多导致数据访问变慢
我们这里提出一些观点和思路:
①：系统冗余，由于我们对数据库的操作频繁导致在后台逻辑业务层和数据访问层中的代码增加，要写一个业务功能，需要观察数据库，找到对应的关联字段，在模型类中添加一个新类，在数据访问层(DLL)--逻辑业务层(BLL)创建各种的新类，在UI层创建对应的页面，然后依次编写代码完善功能。
②：数据库需要优化 分担访问压力
③：系统没有统一的目录，介绍或者说是索引，
解决：我们在开发的过程中总结出一些规律（针对于业务而言）：
①：前端：角色 、权限； 前端的操作无非是增删查改、在这个过程中需要两个东西一个是当前操作的用户、操作的信息
②：后台 ： 对于数据库的增删查改访问大致相同 比如查询单条数据 查询列表 根据参数查询 添加 修改数据
针对此我们决定，再开一个小组，准备开发一个新的框架，以适应现在的业务：
①：前端：创建一个新类basePgae(baseController(控制器)) 添加一些默认的操作 创建一个属性id 获取请求中的Requert的Id,添加验证StringNotNull(要验证的字段，字段的名称，字段的长度)、IntNotMax(要验证的字段，字段的名称,该值的最大值);等等，比较重用的方法，尽可能的封装在这个类中，在以后的开发过程中前端页面继承此类即可，在访问修饰符为Private私有时，程序编译后生成BLL文件屏蔽内部信息，比较安全
②：后台：创建一个基类BaseDLL为泛型类，添加Add、Update、Delete、Get 等通用方法，使用泛型<T>获取要操作的类型（对应的模型/数据库对应的表），用反射创建该类的对象实例，根据这个类的信息去操作对应的数据库表，在这个过程中可以将参数作为一个键值对的集合，进行验证后 将参数拼接到Sql语句中，同样我们可以为这个操作提供一些重载，必要的分页，获取受影响行数，获取记录总数等等的一些方法，
③数据库：在BaseDLL中开放出数据库连接字符串这个位置，让其可以接受参数传入，达到的效果应该时，我的一个业务程序集也就是类库，脱离于前端存在，不需要依赖前端的配置文件传入数据库连接，
So,现在我们再来整理一下我们的系统，系统更新框架后,原本的系统不需要改动（有需求的话可以改动），在继续开发的过程中，我们前端人员只需要负责好前端的样式（控件、布局）等等一些东西，但是所有的操作不会基于后台数据，在和后台交互的过程中会使用开发人员给定的一个访问地址也就是Ajax中的Url，在一般的调用中（一般处理程序、WebServer、MVC）调用中往往我们需要这样书写URL //网址/路径/访问的访问（Action/标记），因此我们也可以说是面向接口，工作中人员常常提到接口接口，主要是指一个访问的地址，其次在后台，添加新功能时，需要创建对应的实体类，随后创建Bll层继承BaseDLL就可以获得通用的方法GetList<模型类>()查询所有、GetGetList<模型类>(参数键值对集合)/、Add(要添加的对象)等等方法，而在控制器，或者和前端交互的类库中我们需要创建一个新类继承basePgae(baseController(控制器))，创建对应前端控件的属性等一些操作（详细请看我之前的随笔，关于框架设计的部分），准备完成后，比如我希望在添加的时候获取一个对象的信息，我们可以直接Bll.Get(id);因为基类中我们定义了Id所以在这里可以使用，避免我们再次从请求Requer中获取，"只有规范的基础才有可能去搭建一个框架，框架也要求我们在使用时去遵守一些规约"
Ok,继续开发，现在我们有了新搭建的框架，开发的效率当然也提高了不少，可是生活总是不会让我们如意，这不前不久数据库出现了奔溃，访问太慢了，因此英明的我决定，"分布式"部署数据库和程序，不过首先我们要来回顾一下我们的系统，首先我们接手了一个校务管理系统，经过讨论后我们决定先行开发学生管理模块，在这过程中我们出现了一些问题，但是都被我们克服了，但是随着子系统慢慢的完善，集成到总系统中出现了问题，因此我们决定用分开部署的方式缓解其中的压力，
Lef's Go:
首先让校务管理系统系统部署在我的电脑，当然我们会购买域名了，但是当大家访问时，其实是我这台电脑（服务器）为大家服务了，随后当大家访问子系统学生管理时，我们的程序会去运行我本地的程序集，当需要更新数据的时候会访问到我们程序员小王的电脑，为什么呢？因为我们在程序集中配置了数据访问层的配置文件，将子系统学生管理数据库连接配置成了小王的数据库，这样请求发送到小王数据库完成后，再返回给我由我来做处理，依次推之，我们美美哒的小芳当之无愧的获取的图书馆系统的部署，这样一来，我们就将数据库的压力缓解到了其他的电脑，运行其他电脑的为我们计算工作！！ 我是不是很英明神武啊 (●ˇ∀ˇ●)
哎，我觉得自己太棒了，这不前两天省局的人找过来了，说想调用我们的接口（程序），完成一个图标汇总的功能，要奖励国家奖学金啊，这感情好啊是吧！但是我一想这不行啊，虽然我将数据库的压力缓解了可是程序的运算可是都放在我的电脑的呀，要是为省局这件事，我的系统可能要炸啊：
问题出来了，虽然我们的程序将数据库部署分开了，但是实际上关于项目的运算都是集中我这一台电脑上的！怎么办呢？有了我使用服务来做这一件事（微服务、服务开发），
为什么要用服务呢（WerServer、Wcf、一般处理程序），因为我们在访问服务时，数据不需要我们来处理，想想看，我在百度查询<黄家驹>，并没有在我电脑本地运行程序，然后去对应程序集查询然后对应数据库吧，而这一过程显然是交给了百度，谁让人家有钱买得起好的电脑呢（服务器），也就是说我不在使用引用程序集的方式去部署我的校务管理系统系统，而是转用服务的访问，
现在我们程序运行的方式应该是这样的：登陆校务管理系统，一些页面的浏览由我本机提供，但访问子系统图书馆管理时就将这一请求发送到了我们美女程序员小芳的电脑，小芳电脑的服务器（IIS、Tomacte）接受到请求后开始解析，指定对应的程序集，开始运行判断 访问数据库，返回数据 最后在接处返回