博客园_桀骜的灵魂

ExtJS & ASP.NET MVC3.0 学习笔记三

2011-07-16T13:36:00Z

系列目录

ExtJS & ASP.NET MVC3.0 学习笔记四

正题

今天，我们来学习一下Ext.Template，这个东西究竟有什么用呢？这是我当时看见它的第一反应。顾名思义，Template即“模板”，很直观的解释，但放到程序上来就不好理解了，而我自己对模板的定义是“静态不变的东西”，而究竟这里是不是这个意思呢？是不是其实不重要，重要是它是用来解决什么问题的，我们为什么要用它？如果叫我用文字来说明它的好处，我办不到，因为我看了API文档和网上后，都觉得文章解释不能是什么好处，开篇都是用法，所以我决定用一个例子来证明它是有好处的！其实它的好处是“重用&简洁直观”~XD，不过单纯这么说，你肯定会说我是在忽悠你。好吧，开波！

例子

作为Web开发人员，前后台的数据交互是我们的家常便饭了，这里的数据交互指代的是View和Controller的数据交互，我习惯用Json作为传输数据，所以这个例子也不例外，不了解Json的朋友可以先去了解一下，这里就不解释它是什么了。

要解决的问题是：

“后台向前台传递一组Json数据，前台根据这组Json数据动态渲染出一组新的HTML标记符。”

看到这里想必大家都心中有数，先看看我们的Json数据。

为了更好地说明问题，这个例子中有一部分代码是用JQuery来写，不是ExtJS!强调，以下代码是JQuery!看看解决问题的代码。

运行！

如果你懂JQuery，这里的代码不难理解。遍历后台传来的Json数据，拼接一组动态生成HTML标记的字符串，然后插入到表格table1里面，解决了。然而，问题来了，现在这段动态拼接的字符串要插入的不单单是table1,还有要插入到table2，糟糕了，难道我要复制粘贴这段拼接逻辑，再修修补补实现变更了的需求？！我想你不会这样做，可能有一部分人还是会这样做，但问题极限化成100个Table都要有相同效果，你就肯定不会再这样了，因为只要有一处地方要修改，这也会是要命的结局。面对这样的要求，我们一定要把不变的东西抽出来，实现“重用”！修改一下。

再看一下看HTML结构

运行

抽出了Func方法后，我们实现了重用的目的，现在不管多少个Table要相同效果，我们都不怕了，增加一条调用Func函数的代码就OK了，但仔细看了看Func函数内部的逻辑，是不是有种不太理解的感觉？看上去就不知道想表达什么！……*……*%~改！改到直观为止吧！

运行

是不是感觉清爽了很多？这是为什么呢？其实只不过是把拼接HTML标记的部分分离出来而已，分离了就直观很多了，这是我们的感觉。正因为分离了，代码变得好理解了，变得“简洁”起来了！而这里的Tr_Template函数就起到一个“模板”的作用了。写到这里，我们不要再流年在JQuery的做法了，是时候回归我们今日的主题Ext.Template了！

Ext.Template

这里就不解释了，直接上替换刚才用JQuery实现的代码。

运行

其实开篇就说到，Ext.Template的好处是“重用&简洁直观”，当做到分离“展示”和“数据”，就能体现这些优点。而要注意的是Ext.Template下有一个方法。

compile() :将模板编译成内置脚本调用函数,并且消除了正则表达式的符号，可以提高执行效率。

结语

小小的功能演示用了这么长的篇幅，汗颜中~无语中！

本文链接

ExtJS & ASP.NET MVC3.0 学习笔记二

2011-07-15T12:28:00Z

系列目录

ExtJS & ASP.NET MVC3.0 学习笔记一

ExtJS & ASP.NET MVC3.0 学习笔记二

ExtJS & ASP.NET MVC3.0 学习笔记三

ExtJS & ASP.NET MVC3.0 学习笔记四

正题

今日我们来看看ExtJS下的两个UI组件，Button和Window，如果你曾经用过JQuery，这两个东西也不会很陌生。在我看来，这两个东西都是在开发中经常用到的，几乎每一个Web都会用到Button，Window可能不多，但也是必不可少的东西，所以我们来扫一扫ExtJS下的Button和Window。我粗略地翻了翻ExtJS的API文档，我发觉这两个东西都有不少属性和方法注解，作为一篇文章，准确地说是学习笔记，应该把常用的部分罗列出来，给ExtJS初学者一种直观的使用角度，对它的UI组件学习产生兴趣，所以我不打算把所有属性都描述一遍。作为笔记不应该太多废话，好吧，不墨迹了。

Ext.Button

ExtJS果真很面向对象，明确的类，完整的继承体系，这么直观，想必也不用我废话了~XD，我们来看看应用代码

这里的@section JavaScript上篇有粗略介绍，不了解的朋友可以看看上一篇笔记，这里就不再解释了，Button的属性都很直观，但要注意的是以下3点。

Ext.getBody():是EXT对document.body的封装，获得Body DOM节点的内容。

renderTo:文档解释是把Render产生端作为目标元素的子节点，我对这个解释存在疑惑！

handler:用于指定触发的函数，默认的是点击事件。

我们看看运行效果

点击一下

一个普通的按钮，平时我们实现这种效果，首先要写一个创建按钮的HTML代码块，再根据需要加入脚本去赋予其交互功能，而这里只需要写脚本就实现了平时我们要做的两样东西了，有种简化工作任务的感觉吧？或许你会说，“最终其实也是HTML，前端还是手工写HTML实在！”这个是当然的了，好不好见仁见智了，我个人认为，学习的时候更复杂更多的代码都不怕，但真正上到工作上，效率才是王道，前提是优雅~XD。

Ext.Window

和Button一样，Window也是作为子类，它继承自Panel，顾名思义，看它的爸爸就知道，它也是一种容器级别的组件，承载东西用的。看看应用代码

何其简单的代码，属性我也不多解释了，要注意的是

show():显示该组件，用于返回Ext.Component

看看运行效果

总觉得ExtJS有点高档货的Feel~XD，或许是我大乡里出省城吧。

现在我们试试把Button放到Window上面，由于一日精力有限，没有太多时间研究下去了，只能凑合节约时间，试试，诸君如果有更好的做法留言一下~XD。先看看代码

运行~:)

结语

ExtJS给我的感觉是挺省力的，纯手工的HTML活做多了，说真的有点厌烦，再加上本人对CSS并不熟悉，UI美工就我的痛，我相信ExtJS一定会给我带来改善UI工作任务的力量！而很久之前我一直就想在JavaScript的环境下更OO地写代码，今日的ExtJS学习果真给了我这种久违的感觉。

本文链接

ExtJS & ASP.NET MVC3.0 学习笔记一

2011-07-14T13:19:00Z

导读

本这个系列主要用来记录我在ASP.NET MVC3.0上应用ExtJS学习的过程，而MVC3.0的技术可能只是作为穿插，并不深究。而强调的是我也是ExtJS入门级菜鸟。

我认为，用一样东西，首先应该给自己一个理由。所以我要先说说我学习ExtJS的理由。ExtJS并不是我学习的第一只UI框架，在选择它之前，我已经使用了JQuery 1年了，对比原生的JavaScript，JQuery让我很得意，能做到一行代码换3行原生脚本代码，用简洁来形容JQuery一点都不过分，累积了几个应用JQuery项目的经验后，我总结出我对JQuery这个UI框架的看法，它的插件品种繁多的，让人觉得它无所不能，可以说，你能想到的插件，都有人做了，有种手到拿来的感觉，活着JQuery的世界真好！但当我深入后，发觉这些多不胜数的插件是显得有点混乱，为什么这么说呢，不同的浏览器的兼容性问题，插件本身和JQuery的版本的兼容性问题，是一件让我觉得简洁的背后是要付出代价的！当你熟练运用了一种第三方插件后，发觉在新版本框架下，它存在兼容问题，作为使用者，我持有的是拿来主意态度，如果因为兼容问题，还要折腾一天两天去自我调整，偏离了我的使用意图，这是为什么呢？因为它缺乏一个标准，没有特定的组织去维护它，大多数是靠数人业余组织或者是个人来支撑它的成长，很快这些插件就会没落。或许是我眼界窄，没看到JQuery下出色的UI集成框架，而另一方面是，我觉得JQuery维护的成本其实并不低的，总觉页面也应该OO点，根据以上问题，我决定从新开始学习一个新的UI框架，它就是ExtJS。

在学习前，我搜索了一下在园子里讲述ExtJS的相关文章，发觉很多有关ExtJS的文章都是实际应用方面的，有很强的实践性，但并不是入门级的文章，对于类似我这种连门都没摸清的学习者来说很难理解，觉得无从入手，还不如看看官网上的例子来得实在，所以我要记录这个连门都没摸清的学习过程，以最简单最常用的随笔记录这个过程。

系列目录

ExtJS & ASP.NET MVC3.0 学习笔记一

ExtJS & ASP.NET MVC3.0 学习笔记二

ExtJS & ASP.NET MVC3.0 学习笔记三

ExtJS & ASP.NET MVC3.0 学习笔记四

正题

让我开始这个过程吧，国际惯例，开篇传统例子，Hello World~XD

首先，使用ExtJS之前，要先下载ExtJS的脚本库文件，打开官网http://extjs.com/ 下载到本地先。我下载的版本是ExtJS 2.3.0，由于我还不清楚哪一个版本是免费，听说是3.0以上的版本是收费的，所以我下载了一个低版本来试试手。

把下载了的脚本库解压，引入到我们的WEB项目，当然这里要先建一个ASP.NET MVC3.0的空项目。如下图

然后新建一个HomeController，在Index() Action里右击添加一个View，在添加View的时候，我们选上我们的Master Page :_Layout.cshtml 并编辑它，如下图。

1.ext-base.js:ExtJS基础框架库。

我们看看引自《Action in ExtJS》的解释“ext-base,which is the base Ext JS library,which is used for an all-Ext JS setup.”。

2.ext-all.js:ExtJS核心库。

主要注意的是这两个库的引入顺序，如果反了就会出现对象为空的报错，原因是，这两个库存在引用关系。

你应该也留意到RenderSection，这个是MVC 3.0带来的新特性，意图是给子页面预留一个存在于母页的桩位，而具体要实现的内容由子页去完成，内容可以是脚本或者是其他HTML构造块等等，体现了共性中的特性。这里我们就插入一个脚本桩。这个方法，第二个参数如果为true，就表示每一个子页都要实现这个块的内容，不然会报错，如果为false就可实现也可不实现，默认为false。我们先实现这个块的内容，而Renderbody是子页在母页的一个HTML Body内容桩。我们创建一个子页面/Home/Index，如下图。

这里简单描述一下这段代码，section JavaScript是实现母页的区域桩，而里面填充的是脚本内。Ext.onReady(Function fn,Object scope,boolean override)会在页面加载完毕后执行，和原生Javascript的window.onload功能是一样的。最后运行结果如下图

本篇结语

第一天感觉ExtJS和JQuery的语法差不多，当然初探还没有JQuery简洁，但可以感受到，它的UI渲染效果是挺企业的，XD

本文链接

【转】四色原型-第一印象

2011-07-14T00:09:00Z

此文转自http://blog.csdn.net/asukamk2/

如果说设计模式、分析模式分别是对OOD和OOA的提炼与精化，那四色原型可以说是对需求分析的提炼与精化。复杂的东西总是可以通过简单的东西组织、表达出来。软件工程中也是如此，任何需求都可以抽象成四色原型中的四种角色之一：

moment-interval archetype（MI）:是四色原型中很重要的一个原型，它具有较强的时间属性，表达了某时某刻（或较短的一个时间段内）的一件事情，比如“晚上11点观看西甲联赛”。moment-interval archetype使用粉红色标示。

role archetype(RO):表达角色，概念跟平时说的“角色”比较相似。任何一项活动都需要人或组织的参与，这个时候人或组织就从属于某种角色。角色需要通过具体活动确定，也就是说这个人或组织需要从事这项活动，才属于这个角色。比如一瓶洗发水，它放在货架上的时候角色可以是“待销售的商品”，当有人把它买回家之后，它的角色就转变成“使用中的商品”。个人感觉角色这个概念跟OO中的“状态”比较相似。角色使用黄色标示。

party, place, or thing archetype（PPT）:活动必须有人、组织的参与，人、组织是一个主动的概念，它能够管理自己的行为并驱动活动。活动场景下的人、组织或事物具备唯一性，它们通过唯一标示与其他个体区分开来。比如课堂上的小郑、小刘是两个独立的个体，Nission生产线上的GTR-20081115-001和GTR-20081115-002是两个独立的个体。PPT通过绿色标示。

description archetype(DE):描述表达了个体中公用的一些特征，比如每一辆GTR都拥有车牌号、方向盘等属性。DE使用蓝色标示。

下面是一个通过四色原型表述的简单例子，Asuka作为一个PPT，当他在公司工作的时候从属的角色是Architect，它正在DesignESB，而对Asuka有一些通用的Description。

感觉四色原型可以映射到领域驱动设计（DDD）中，比如DE原型描述了公用的属性，在DDD中以值对象（ValueObject）表达，PPT原型描述的是某个场景下唯一的个体，也就是DDD中的实体（Entity），而MI表达的是从事的活动，就是DDD中的服务(Service）。RO原型在DDD中没有直接对应关系，不过我自己觉得它描述的是PPT的状态，可以和PPT一起构成DDD中完备的实体--唯一标示的个体，并且拥有状态。

下面是DNC提出的一个通用的四色原型模板，学习之~

四色原型是比分析模式还抽象的东东，现在也只是一个大概的印象，还需要在日后的OOA/D中好好体会^^。

本文链接

【转】四色原型图的思考

2011-07-13T23:52:00Z

此文转自http://yananay.iteye.com

学习四色原型图有一段时间了，磕磕碰碰一路走来，更有理解严重偏差的时候，不过近日总算有所领悟了，把一些想法写在这里，供大家共同讨论。

不过说到四色原型图，大家更愿意一起比较的是“领域驱动设计”，简称 DDD，因此这个讨论也就把 DDD 掺合在一起了。

（关于四色原型图的信息，大家可以自行google，有一个英文版的pdf文件。）

1、Moment-interval

这个图被作为是四色原型图中最重要的一个部分。我想也是最难理解的一个图。原文对它的定义是：某一个时刻，或者某一段时间内发生的业务。这种定义非常非常的抽象，导致我们在使用四色原型图去分析业务的时候，很难确定到底什么是 MI。

那么，到底什么是 MI 呢？去除抽象的定义，以及其他挠头的文字，揭开它的本质，其实它就是业务领域的关键性动词！

例如，销售，报告，结算，确认订单等等，这样关键性的动词，其实都表示一个 MI。

所以，我们也就知道如何发现一个 MI了，在一堆堆的需求文字中，我们要找到关键性的动词，那么它就是 MI，也就是当前这个业务的核心了。围绕着这个 MI，我们会继续发现 ppt,role,desc 等等。所以 MI 神奇吗？一点都不神奇。深奥吗？一点不深奥。

值得一提的是，虽然第一次找到了几个 MI，再经过分析后，很可能这些 MI 会合并到一起--这根据你的需求来设计。

另外一个网上流传甚广，害人不倦的信息是：很多人都说 MI 相当于 DDD 中的 service。这是绝对的误人子弟！通过上面的分析，我们已经知道 MI 必然包含业务的关键性动作，而这类关键性动作，通常是作为领域模型的一个方法，很少会作为 service 的方法。所以，说 MI 相当于 DDD 中的service是绝对的错误，正确的说来，应该是 MI 可能是 DDD 中的 service,更可能是 DDD 中的领域模型。

2、ppt(Party, Place, Thing) 和 role

对于 ppt ，大家都有一个共识，就是 ppt 一般相当于领域模型，而寻找ppt的方式也无外乎就是归纳名词的方式。不过，之前我们一定会先找到 MI，所以这个 ppt 也是围绕着 MI归纳出来的。

Role 是个迷惑大家的东西。因为一提到 role，大家基本都联想到“人”之类的有生命的东西。可是在四色原型里，Role也可能是没有生命的物体。例如，车是一个 ppt，坏掉的车则是车的一个role，良好的车也是车的一个role。虽然我们通常会认为这是车的两个状态，但是这里我们将它设计为车的两个Role。

3、desc
desc这个图的定义是类似目录的结构，起到描述性的作用。大家的共识是它相当于领域模型的值对象----我的理解也就达到这个程度，我觉得用值对象来类比它非常合适，容易让人理解。

4、四色原型，DDD 到底应该选择哪个？

四色原型其实正如其名字一样，是一种分析模式，而不是设计模式。
所以，分析阶段采用四色原型，而在设计阶段采用 DDD 应该是可以的。

其实四色原型也没有什么特别深奥的地方，面对需求文档，我们先找关键性动词，围绕它去找关键性名词，理清业务的逻辑。这是我们常用的思维方式，不过四色原型将这个过程更加科学化，并且用图的方式让这个过程更加清晰。

打个比方：以前我们分析需求是凭感觉，现在则是遵循一定的步骤做。

所以，需求分析，不用四色原型也ok，但是使用四色原型，会更加顺利和清晰。

本文链接

【讨论】在领域对象里，是否应该存在Setter和Getter?

2011-06-24T12:25:00Z

经过上篇【讨论】“转账功能”引发的“谜团”的讨论，获益良多，首先先感谢各位博友的看法，真是醍醐灌顶，在细品评论的同时，我觉得很有必要结合自身对各位博友评论的理解总结出一些什么来反馈一下，所以特此开多一篇文章来，集思广益。

和上篇做法差不多，通过不同做法对比来展开讨论，要注意的是本篇的伪代码完全和上篇没有承接关系，内容上也没有绝对的联系。由于上一篇讨论之前我没有具体说明实现代码实之为伪代码，给部分博友带来不少疑虑，把关注点放到了具体实现上，本人表示十分愧疚！所以在开篇之前先声明：本文说明的代码全是伪代码，大家无需关注具体的实现细节~XD，废话少说，进入正题。

本篇的讨论中心：在领域对象里，是否应该存在Setter和Getter？

为了抛开上一篇说不清的ATM转账用例，这篇拿出来讨论的例子也是非常常见的：“订单管理”，当然这里只不过是简单地展开，没有打算深入研究。

既然是订单管理，进一步细化就是：更新订单（Update Order），创建订单（Create Order），查询订单（Retrieve Order），删除订单(Delete Order)了，这是从我的角度展开的，大家不必纠结还有什么，应该是什么。

回到订单管理上，细化的功能点想必都是大家再熟悉不过的功能了，等价于CRUD功能吗？或许受数据库技术影响，很多人，包括我也是先入为主，很自然地把这些用例当功能来实现，并没有先从领域对象入手去思考，这些用例中是否存在领域行为，可能这里墨迹的东西比较自我理解化，多都包含！我们先来看第一种实现方法吧。

<1>.在Setter和Getter的情况下实现:更新订单，创建订单，查询订单，删除订单

可以看到具体的伪代码实现，是多么的熟悉，要注意的是，这里例子使用了DTO，因为考虑到重载爆炸等问题，不喜欢用简单类型作为参数，文章这里不解释DTO是什么了,因为每个人对概念上的东西理解都会不同，我也说不清，也不敢说自己的理解是对的，有兴趣的朋友可以去Virus兄的博客里了解下，我觉得他对DTO见解很不错，但是本文的例子否使用DTO并不影响伪代码的组织实现，大家不必要深究。

回过头来，上图代码中Order类的属性都是Public的，每个属性都有对应的Setter和Getter。对于4个功能的实现大家都很熟悉，我也问过很多程序朋友，大部分都颇为仍同这种实现方式，这也是我长期以来的做法，很长一段时间我都不觉得这种做法有什么问题，当然现在为止也是点不出问题所在，所以特意拿出来讨论。

结合上一篇评论提到的：Getter/Setter是否提供，是否应该Public 还是Private，还是一个Public一个Private等疑惑，我得出了第二种做法。

<2>.在没有Setter和Getter的情况下实现:更新订单，创建订单，查询订单，删除订单

上图做法是站在没有Setter和Getter的前提下实现的，可以看出，代码量较之第一种做法更为简洁，第一种方式中的代码段大部分被嫁接到领域对象中，在这我要强调的是，我并不认为第二种做法是正确的，我也对这种做法持有怀疑态度。

结语第二种并不是为了说明要替代第一种做法而实现的，在没有明确讨论结果之前，我不会认同第二种做法是否应该存在替代第一种做法，但从代码量来说，第二种做法确实稍为优胜之。而从CRUD说起，是因为大部分人都惯性从实现功能的角度去分析用例，很少会优先从领域行为入手来分配职责，说这句话，或许只是针对我自己，但并不否定很多人都是这么想的。最后回顾上一篇的AMT转账问题，其实如果从没有Setter和Getter出发，就不会存在第一种情况了，也很自然地出现了第二种情况，而第三种做法依然不知道如何解释。

讨论结果：我会总结大家的讨论结果在这里贴出来，请大家保持关注文章结尾这里的讨论结果。我会实时更新。

(*^__^*) ……

本文链接

【讨论】“转账功能”引发的“谜团”

2011-06-22T12:30:00Z

今天拿出了一个憋在心中很久的问题来和领域驱动群的群友讨论，经过几小时讨论，总体上来说还是不能解决我心中的疑惑，所以直接拿出来和博友们来讨论一翻，希望以博客园大家的见识来为我释怀。为了让大家对所讨论的问题达成共识，就拿一个比较经典的ATM转账功能实现来展开讨论。如果我直接说大家都转过账，这未免太绝对了，但我相信在生活中，每一个人都听过这个词，废话少说直接进正题。

讨论的中心：如何从用例(功能)来精炼领域模型。

大家先不要急着回答我的问题，先对比以下落来的3位同学的对“转账功能”的具体实现。

1.甲君实现“转账”的代码

评论：甲君这种实现方式，咋看上去并无问题，或许很多朋友也都是这样去实现转账功能的，包括我在内。

2.再看看乙君对“转账功能”的实现的。

评论：相信看到乙君的实现，各位肯定会喊当然是这种比较好啦，应该没人会说这种方式比第一种差吧，但反问各位这种做法为何好？好在哪里？为何能驱动出这个模型来？或许你们都会答，第二种明显维护的时候更省力什么的。。。我只能说从重构的角度来说，第一种有必要改进成第二种，但从功能实现的角度，抱歉，我无法单纯从转账这个用例精化出这种模型来。

3.看看丙君的“转账实现”

评论：相信有不少人看到丙君的实现第一反应是，这种比前两种貌似都要好，因为从代码量来说它是最少的，所以大家第一反应都会觉得这种更好，而我又反问你们，单纯从一个转账功能就能驱动出如何简洁的模型？究竟巧妙在哪里？每个看过三种实现方式的人都会觉得这种实现方式职责更加分离了，更容易维护了，更。。。就是说不出如何驱动出来的。

其实，我也觉得自己表达不清，所以题目打了两个字“谜团”，只能尽量去描述心中的疑惑：

已知条件：实现转账功能

问题结果：得出一个Account领域模型

结语：单从一个这么狭窄的已知条件去驱动出第二种方法的领域模型，各位你们凭什么得出这个结果?得出Redraw()和Deposit()方法？而第三种方法，又凭什么去把赋予Account对象一个转账行为，凭什么说转账是一个行为，请大家严谨地分析一下。

讨论结果：

经过各位的讨论，大致得出以下比较认同的第4种方案，见下图。

然而虽然说这种方案是大家比较认同的，但我本人觉得绿色框框的部分代码是为了替代转入(Deposit)和转出(WithDraw)功能而定义的行为，从业务概念理解上，很合理，也应该这么做，但始终有种换汤不换药的感。我会把最新的讨论结果更新上来，大家放心讨论和关注此文结果。

本文链接

Unity 在MVC上的应用(扩展篇:JQuery AJAX)

2011-06-16T11:21:00Z

系列目录

Unity 在MVC上的应用(上:思路整理)

Unity 在MVC上的应用(中:Repository)

Unity 在MVC上的应用(下:ORM)

Unity 在MVC上的应用(扩展篇:JQuery AJAX)

Unity 在MVC上的应用(扩展篇:事务控制-前篇ActionFilter)

Unity 在MVC上的应用(扩展篇:事务控制-后篇Unit Of Work)

Unity 在MVC上的应用(扩展篇:日志管理NLog)

正题

回顾上几篇，我说过会在今后的扩展篇系列加入一些常用的技术，所以今天就说说在ASP.NET MVC上的JQuery AJAX应用。

先来简单描叙一下两个用到的东西：

1.JQuery

jQuery由美国人John Resig创建，至今已吸引了来自世界各地的众多javascript高手加入其team，包括来自德国的Jörn Zaefferer，罗马尼亚的Stefan Petre等等。jQuery是继prototype之后又一个优秀的Javascrīpt框架。其宗旨是——WRITE LESS,DO MORE,写更少的代码,做更多的事情。

2.AJAX

AJAX即“Asynchronous JavaScript and XML”（异步JavaScript和XML)，AJAX并非缩写词，而是由Jesse James Gaiiett创造的名词，是指一种创建交互式网页应用的网页开发技术。

好了废话少说，直至进入我们今日的主题。XD

在教你如何使用JQuery AJAX用法之前我们来引入2个在WEB开发方面常见问题。

(1)如果你有用过ASP.NET MVC，你应该会知道，我们在页面提交数据到Controller的时候，是基于POST方式的，而数据的载体是表单，也就是说数据要通过POST方式提交都是在表单里面的，而且每次提交数据都要刷新当前页面，如果想当前页面某一区域(div,table等)的数据保留起来，或者是说某个输入框的数据保留起来不清空这应该怎么办？很明显整个页面的刷新没可能再保留页面的数据了，在这种前提下，我们一般的做法是，把要还原的数据先POST去后台装载，然后再从后台传组装到要返回的数据里面再返回到新页面读取，听上这种做法挺别扭的，你别笑，以前还不会AJAX的时候，也只能这样解决这种问题，相信很多人都试过或者还在用这种方式。

(2)第二个问题是，当你存在一个很巨大的表单的时候，后台只需要很小量的数据来计算,记录什么的，例如一个超巨大的表单，里面有1000个输入框，而后台只需要其中一个输入框的数据，而传统的POST，要先提交整个表单，然后再去调用服务计算什么的，你看看，这样是不是很浪费带宽？只要你极限化看待这个问题，这种做法其实也是很别扭的，我们的口号，要什么拿什么！！

为了解决这两个个问题，我们要使用AJAX技术。也就是我们今日的主题JQuery AJAX!!终于入住题了~(*^__^*) 嘻嘻……

一如既往，从我们上篇已有的DEMO入手.先看看我们的页面，这次先从一个简单的用户登录功能入手教你用JQuery AJAX。

先看看传统的POST方式实现登录功能的代码

可以看出，我们一般都是这样去实现的。

为了实现AJAX提交，我们再写一个新的Action。

功能实现上没什么区别，要注意的是，这里我们发送回去的是一个跳转路径，因为我们要在脚本里跳转。其次要注意的是，也是基于HTTP POST的。。XD

现在开始写我们的脚本了。

代码是写在我们的登录页面的脚本上的，要注意的是，这里的DTO和后台的静态DTO对象是对应的，字段要一致，不然是无法反序列化成功的，而MVC3.0自动实现了对对应的静态类的反序列化，很方便！而这里引入序列化/反序列化概念是因为，我们用AJAX传输的数据是以JSON形式的，JSON数据要在网络传输首先要进行序列化，在接收端反序列化才可以成功读取数据，你可以看成是封包和解包过程，这里的出JSON.stringify(DTO)是用来实现对JSON数据序列化的，而Javascript本身里没有对数据序列化的功能的，所以我们要先引入一个外部脚本库来满足这个需求，看下图。

而这个对JSON序列化的脚本库可以到这里下载： www.json.org

具体实现代码我们就完成了，很简单，现在我们来对比一下效果。

首先看看传统的POST方式。

我们按Submit按钮~

再看看我们的JQuery AJAX方式如何~XD

结果

想必结果都不用我多说了~

本篇结语

希望对你们学习MVC有所帮助。

本文链接

【讨论二】服务层(Service)的功能参数列表的粒度

2011-06-12T05:21:00Z

上篇【讨论二】服务层(Service)的功能参数列表的粒度可能缺少代码段和图片，大家都不怎么来参与，所以在原有的基础上加入这些元素，希望大家能给点灵感我。

我们一般在设计服务层的时候总会有这种情况，究竟参数列表是简单类型还是对象类型？

首先我们从比较常见的场景入手，修改订单。这里我们先不考虑它是否应该归属于领域对象。

根据场景很自然就能提炼出一个功能：EditOrder(XXX)，我们开始看看参数列表的写法的种类。我大概想到3种。

1.void EditOrder(string orderName,string orderText,float Money);

2.void EditOrder(Order order);

3.void EditOrder(OrderDTO dto);

先看看我对这三种设计的见解。

第一种：很直观，也是最早被我们使用的方式，但这种设计有很多弊端。

1)容易造成参数组合爆炸，因为对象的属性有很多，一个参数组合列表不定，两个参数组合列表不定，三个四个组合列表等等若此类推，理论上有人脑处理不能的组合，也就是很难适应变化，你只能不断地加入重载功能到服务层接口里面，并且会出现很多类似的代码段，果断后期悲剧。

伪代码实现：

Order Model

class Order
{
public int id{get;set;}
public string Name{get;set;}

public string Number{get;set;}

public string Text{get;set;}
public float Money{get;set;}
public DateTime CreateDate{get;set;}
}

按照第一种思路具体对Service功能的实现

void EditOrder(int id,string orderName,string orderText,float Money)
{
Order order=this._OrderRepository.find(id);
order.Name=orderName;
order.Text=orderText;
order.Money=Money;
this._OrderRepository.save(order);
}

2)使用简单类型作为参数列表，在一定数量级的情况下，会出现重载冲突，如

void EditOrder(int id,string orderName,string orderText,float Money);

void EditOrder(int id,string orderNumber,string orderTitle,float Money);

显然这个重载方法会有编译错误，为了迎合这种需求，你只能通过修改方法名字来满足，十分别扭。以下是修改了的代码

void EditOrderNum(int id,string orderNumber,string orderText,float Money)
{
Order order=this._OrderRepository.find(id);
order.Number=orderNumber; //把Name改成Number属性修改
order.Text=orderText;
order.Money=Money;
this._OrderRepository.save(order);
}

从这个修改结果可以看出，存在很多重复代码段，都是类似代码，即不能复用，也不能不写，而且当需求不断变化，这个服务层就越来越厚，也是上述文章提到的弊端之一。

第二种：直接使用领域对象作为数据载体，好处是能够适应所有围绕领域模型的需求变化，解决了第一种情况不断重载的局面，也随理成章地解决了重载冲突的局面。然而这里存在一些弊端。

1)由于数据载体是一个领域对象，调用端传送回来的数据可能只有几个属性，也就是很可能存在大量的null值和默认值的属性，面对这种情况，我们要在功能实现里面对对象属性进行筛选验证，当然只有几个属性这不能当一回事，但领域对象大起上来，有几十个属性或以上，这部分工作就变得痛苦起来了。

按照第二种思路对Service功能的实现

void EditOrder(Order data)
{
if(data.id!=0)
{
Order order=this._OrderRepository.find(data.id);
if(!string.IsNullOrEmpty(data.Name))
{
order.Name=data.Name;
}
if(data.CreateDate!=new DateTime())
{
order.CreateDate=data.CreateDate;
}
this._OrderRepository.save(order);
}
throw new Exception("Error");
}

要注意的是，这里的Order data参数，只充当一个数据载体，而不是一个领域对象。

第三种：使用DTO代替领域对象作为数据载体，其实我也用过这种做法，但我找不到其好处，引用别人的观点就是，隔离了领域对象对UI的影响，安全性得到保证，从我的实践经验来看，确实是把领域对象隔离出UI，但换来的是大量的DTO管理和适配问题，这些问题比维护问题还头痛，如果是单纯从分布式的角度来解决问题，结合第二种和第三种做法可以产生一变种，前端返回给后台的数据载体用领域对象，而前端接收的数据载体用DTO。

结论：第二种做法是暂时面对非分布式开发是下比较好的做法，但总感觉有点别扭，所以把问题拿出来，集思广益！希望大家积极参与！我相信你们的经验中一定有更好的解决办法。

本文链接

【讨论】服务层(Service)的功能参数列表的粒度

2011-06-12T03:19:00Z

我们一般在设计服务层的时候总会有这种情况，究竟参数列表是简单类型还是对象类型？

首先我们从比较常见的场景入手，修改订单。这里我们先不考虑它是否应该归属于领域对象。

根据场景很自然就能提炼出一个功能：EditOrder(XXX)，我们开始看看参数列表的写法的种类。我大概想到3种。

1.void EditOrder(string orderName,string orderText,float Money);

2.void EditOrder(Order order);

3.void EditOrder(OrderDTO dto);

先看看我对这三种设计的见解。

第一种：很直观，也是最早被我们使用的方式，但这种设计有很多弊端。

2)使用简单类型作为参数列表，在一定数量级的情况下，会出现重载冲突，如

void EditOrder(string orderName,string orderText,float Money);

void EditOrder(string orderNumber,string orderTitle,float Money);

显然这个重载方法会有编译错误，为了迎合这种需求，你只能通过修改方法名字来满足，十分别扭。

本文链接