设计思想

 

小菜白话搭架子4：不再迷信某些设计思想

2014-01-25 11:01 by Turbo Zhang, 602 阅读, 4 评论, 收藏, 编辑

首先解释下“不再迷信”不是不信和不用，而是为了更好的思考与使用。

故事起源与最近用Python做的类似于网盘的项目。由于之前更多使用的是高级语言（C#，Java），这种面向企业级的语言为得就是解决繁琐且负责的企业需求。于是设计模式的运用是必要也是必须。

但是由于最近的工作内容更多的偏工具，脚本，自动化。使用的C#就比较少了。

用Python的过程当中需要为方法传一个数组，突然恍惚了一下“针对于复制出来的数组使用时是默认是值传递还是引用传递呢？”。

类似于：

小菜之前一直以为只有通过ref才可以呢。类似于：

没想到效果竟然一样。于是就思考由于语言有自己的特性，习惯性的解决惯性可能会影响我们的一些判断和发挥。

由于做的是国外项目，陆陆续续的会看一些老外的代码，参加一些老外培训，查阅代码的过程当中，会发现一些有意思的东西，其中一点就是，老外似乎不怎么迷信某些常见的设计思想。

比如：

    代码重用。

    以前在公司也会有很多的大牛，或者其他的一些例子，其中代码重用的呼声很高。在这次的项目中我会经常见到DB的Connection几乎会在每个WorkFlow中见到，我想如果是我以前设计的话一定会单独建一个类库去处理所有的数据访问相关的工作，在上层代码肯定不会见到DB的操作，这样才能更好的实现面向对象的某些要求，也更能体现出作为程序员的能力，但是他们这样做肯定是有原因的，我在想如果将我的那个思想放在这里会怎样呢？

    首先由于目前的项目的整个Process的周期很长，于是会有不同的人陆陆续续参与进来，也有很多人会调离出去。也会有不同新的WorkFlow陆陆续续加进来。DB操作的封装首先会造成新接手的人员对Process的理解成本，同时加大了Debug的成本；其次由于项目不同的WorkFLow会连接不同的DB之上，同时每个WorkFlow设置有不同的TimeOut时间于是当我们需要在封装那里去实现更多的配置信息时，实现的复杂度也就提高了，复杂度提高代表出错率提高了。最后如果某一个节点需要更优的处理比如引进NoSql，Hadoop我们同样需要在封装端加更多的方法和配置，于是编代码变成了“便”代码。

    后来我想起之前犯过一个错误使用MongoDB的时候我在底层修改我的数据连接用来适配SqlServer和MongoDB，在程序使用是报了一个mongoDb的使用错误类似于事物的，后来找了好多希望通过C#实现对MongoDB的这个错误的实现，结果徒劳了。其实MongoDB的API已经是封装好的了我们在用代码封装一次并不能体现我们聪明。

    最后加一个类似于年终总结的东西：

    其实不太喜欢写更多有代码的例子，首先是代码写的并不好，分享给大家也没什么意义。第二一个本人也是喜欢看一些思想上的东西大段的代码也是很少看的简单的推荐几个大牛的Blog，读他们的文章会得到不同的写代码的乐趣，就像中奖和当父亲高兴的不同，也希望大家能给我推荐其他大牛的Blog。

    http://www.cnblogs.com/netfocus/

    http://agiledon.github.io/

    http://www.ruanyifeng.com/blog/

    话说当时面试的时候老大问我未来两年的计划是什么？我说要脱离“微软”程序员，做个程序员，在做软件工程师。他问“有什么不同吗？

    ”我说微软的技术栈里我最喜欢的是C#还有VS，不喜欢WCF的复杂，不喜欢WinServer管理，不喜欢SqlServer的分布式，不喜欢IIS的Debug。

    然后我是一个属于编程语言爱好者，语言榜单前10几名都了解过，但不够深入，也不想深入，我了解的目的不是为了说有多牛，而是为了知道我真正喜欢什么和为什么喜欢，同时给自己一个理由，理由真的很重要。有人喜欢高贵典雅的教堂，有人喜欢鸟语花香的郊外。

    程序员更多的是解决问题，而工程师我认为应该显得更加厚重，比如我喜欢那些领域涉猎广的大牛：计算机，软件，硬件，网络，各种协议，各种标准，经济，政治，历史...也就是说有人把把编程当工程，有人当工具，有人当玩具。

回首做开发的两年算是对编程入了门也更加热爱这个行业了，新的一年争取成为软件工程师，由于工作的变化有机会做Windows Azure的东西，微软的云平台是个想的开放的平台，当时老大说Windows Azure最大的错误就是叫“Windows"，同时微软开源公司也在上海成立。所以新的一年微软会在开源方向走的更多，微软技术栈的同学们也应该接触一些开源的东西。如果说之前对于开源世界只是打开了一扇窗，希望明年能够走出自己的门去拥抱。

快要回家了，较兴奋。想了一下并不是因为快要回家所以兴奋，更多是因为回家之后将迎来崭新的一年，崭新的未知，之前一直以为人会因为未知而恐惧或者恐惧未知。但是现在想想同样因为未知而兴奋，而充满想象，为什么呢？主要是场景不同，在《电锯惊魂》的场景中，每一种未知都是更大的恐惧，而在旅行的列车上，前方更让你充满想象，用春哥的话就是：当你向着阳光奔跑时，脸上怎会看到感伤？即使是感伤，也是对于奔向的是希望的远方，快乐的向往。

 

 

分类: 人在囧途, 项目展示

一个前端与后端分离的架构实例

2014-01-25 11:38 by 麦舒, 781 阅读, 13 评论, 收藏, 编辑

看了《系统架构：Web应用架构的新趋势---前端和后端分离的一点想法》 这篇文章，对前端与后端的分离非常认同，这样做对于系统的维护是有相当大的好处的。正好自己也设计了一个这样的系统，于是把它拿出来，和大家讨论一下。这个架构，与其说是想出来，还不如说是我做系统总结出来的最佳实践。

我们做的系统，前端的页面基本都是使用 JavaScript 的富户端页面，主要应用的框架用，jquery、jquery ui、knockout js、Durandal、另外，还有自己封装的一些 UI 组件，后端的主要采用到的技术有 OData、MVC、Linq to SQL 以及自己写的一个权限管理组件，数据库采用的是 SQL Server 2005。

下面向大家介绍一下各模块的功能以及其划分的目的，我们先从用户界面看起吧

一、关于前端的 dataProvider

简单点说，就是一个给界面调用的数据访问层，很多人都人这样的疑问，在这里加一个数据访问层，是不是多余？只要你做的前端，你都会碰到下面这些问题：

1、一个产品或者项目，前端与后端是同时进行了，这时候，根本没有后端的接口，甚至可以说，连个接口的定义都没有。作为前端开发人员，你如何去开展自己的工作？

2、作为前端开发人员，你有没有碰到，因为后端的接口挂掉，导致你的工作没法继续做下去的情形？

3、作为前端开发人员，往往免不了要和第三方的接口进行对接，你有没有碰到过，和你做对接的人员，突然因为项目紧，被抽走了，留给你的只有一堆需要传N个参数，传了后接着出“对象为空”的异常呢？你根本不知道哪里参数传错了。面对这些接口，你除了破口大骂，得不到任何帮助。

4、作为前端开发人员，你有没有试过，你向后端的开发组，要一个接口，他们需要讨论个几天，然后再花几天才能给你，给你之后，还不能用，又得再花几天时间调试呢？

如果你向我一样，都曾经都碰过这些问题，你就不会怀疑这个 dataProvider 存在的必要了，有了这个 dataProvider，可以最大减少后端接口对前端开发的影响。下面是一个 dataProvider 的实例：

var dataProvider = (function () {

    var fakeProvider = {
        countries: new Countries()
    };

    var realProvider = {
        countries: new JData.WebDataSource()
    };

    //下面的接口，根据情况二选一
    return fakeProvider; //这个是假的 dataProvider，从本地读
    return realProvider; //这个是真正 dataProvider，从接口读
})();

从上面可以看出来，这个 dataProvider 使用了工厂模式来创建，它有两个实例，fakeProvider和realProvider，fakeProvider是用来提供一些模拟数据，而realProvider提供从接口读取出来的数据。当没有接口，或者接口挂掉，我们可以先从 fakeProvider 来读取数据。等接口好了，切换到 realProvider 。

二、关于用户界面输入的验证

1、数据的验证。用户在界面输入数据后，接着调用 dataProvider 里的接口对数据进行处理，但是在向服务端提交之前，得先对数据进行验证。那个这个验证如何进行呢？dataProvider先从服务端获实体的描述信息，这些描述包括但不限于：主外键、属性的验证信息（比如是否可空），当然，这个实体信息是可以缓存起来，以便重用的。然后 dataProvider 再根据这个描述信息来对数据进行验证。

2、错误信息的显示

当验证到某一个属性不合法，验证信息的模块就在页面查找出对应输入控件，它是怎么查找的呢？比如说，Contry 的 Name 输入为空是不可以的。那它就先查找 id 为Coutry的元素，然后再Coutry元素下面再找id 或者 name 为 Name 的控件，如果找不到则直接弹窗显示错误信息。例如：

<form id="Country">
       <input name="Name"/>
</form>

 

三、关于后端使用 OData

1、作为后端开发人员，你有没有碰到过这种前端开发人员，今天让你加一个字段，好，加了，然后打包发布。明天又让你加一个字段。后天突然又说，前两天加的字段，不需要，你会不会有种想喊“操”的冲动？

2、作为后端开发员员，你有没有碰到过这种前端开发人员，今天跟你说接口不够用，要加个 GetUserByName 的方法，明天又说，还得加个 GetUserByEmail 的方法？然后，过了一段时间，你发现接口越来越多，维护的模块越来越痈肿，并且这些接口，你只敢加，不敢删除。因为，你根本不知道这些，有哪个不用的，你跑去问前端，他也回答不出来。所以一些接口哪怕是没用的，也只能永远系统里，直到它生命周期的结束。

如果你也碰到类似于我这种烦恼，使用 OData 也许是一个不错的选择，把查询的权限都开发给前端的开发人员，他爱怎么查就怎么查，都由它去。

四、关于后端使用MVC

我们的系统，使用MVC都是用来处理从前端提交上来的数据的，使用它主要是开发人员都熟悉MVC，然后MVC再调用业务层代码，同时，还需要处理:

1、对提交上来的数据进行验证

2、处理系统的异常，包括对异常进行重新的包装，再传回到客户端，以便于客户端的处理。对异常的信息进行记录。

五、数据访问层

 关于数据访问层，在我们的系统里实际是一个 ORM 的包装器（ORM Wrapper），你在对 ORM 裹上一层外衣。目的在于：

1、对数据进行拦截。例如：有些数据，只对某个角色的开发。数据访问层需要对根据过滤条件，然后再结合查询条件，重新生成SQL。

2、对数据假删除的处理。见过很多系统，都是把删除放到业务层来进行的，其实这是不适合的，从业务的角度来说，关心的是删除，在执行删除后，这条数据从我眼前消失就可以了。至真删除还是假删除，这与我无关。数据访问层，要做的就是这工作，它可以数据在真删除与假删除之间进行切换，只要配置一下，就可以把真删除变成假删除（其实就是把Delete操作变成Update操作），使得进行业务开发人员，不用再关心数据的真假删除。

3、对数据进行跟踪、备份。你肯定碰到过这么一种需要，需要记下来，每一次的更新操作的时间，以及更新了些什么内容。对于删除的数据，能够把它还原回来。数据访问层，通过对 ORM进行包装，完全可以记录下每一次更新、删除这些操作，然后记录下来即可。当然，这些需求利用数据提供的功能也是可以实现的，不在讨论的范围内。

 

这篇文章到此结束，欢迎大家的板砖。

PS:过年的时候，我会把 ALinq 和 Visual Entity 更新到 2013，各位用户就别催更了，最近实在是忙，抽不出时间更新呀。

 

 

公司招聘

初级程序员：懂 JQuery、JQuery UI、JQuery Validate、Knockout JS 等JS 框架，略懂 Linq to SQL，能阅读文档，根据文档示例写代码

中级程序员：有阅读上述框架的