Desktop/Web App

本帖主题和之前写的东西感觉会有好多交叉，不过看来是我较关注的了。
而以下内容并感觉是没有写得很展开或有深度。

传统命令行程序可以
运行时加参数，然后返回状态值并在标准输出里显示内容，并造成副作用。
此外也可用从标准输入获取数据。以文件读写和系统环境交互。
这种程序的代码结构对C语言的程序来说是很典型的。可以在HelloWorld的基础上通过添加实现功能的代码来实现程序的需要的目的。

另一种是有更强的交互功能，用户可以根据输出的提示和要求进行输入或选择。这就如同现在所见所见的向导模式。想对用户友好是一方面（这里不涉及CLI与GUI优劣的讨论），不过在这种模式下，程序运行不是单单为获得结果。在程序运行的一段时间（用户不再是仅等待用户结束）内，用户的交互会和环境的变化之间产生影响。

下面是说到GUI，以Win32为例，这只是我暂时仅了解这个，不过它也比较典型。在程序建立空白窗体后，进入消息循环。代码根据消息的种类选择合适（有部分参数，但可去读文本框之类的输入内容）的操作。在获得载入消息时，可以在窗体上再绘制或调整需要的内容。

用物件导向来说（这里不是数据抽象的话题，因为那是Obj的另一个用途，或许这里我也会说错了），有属性，事件，方法的概念。属性可以分解为get和set两个消息，方法是消息Call可用以提供功能。事件是物件获得消息时被触发的或查询到环境有需要注意的变化。不过在GUI的编写中，通常是用一定的方式让事件和自己编写的执行操作的代码（一般封装成函数形式，也可以是成员函数，继承之类的东西，虽然我觉得叫方法会更好听，其实就是函数了。算了我说乱了。）进行绑定。

如果忽略掉与绑定有关的部分，那么可以看到的是窗体，窗体的代码，各种模块（非GUI而提供功能的部件啦），以及系统调用的封装。

下面转向Web App，如今它和Desktop App之间的距离正在缩短着，也产生了一些让人很有新意（其实更多是从使用上让人感到有力量的东西）的效果。

根据CGI标准，也就是从它的原理来说，就是按照一定规范编写的CLI程序。用户访问网页，则cgi被执行，向标准输出返回内容，比如可以是以Html格式的，即能被浏览器解析的网页。之后，cgi程序进程即被终止。URI和Form可以被用来向cgi输入内容，并供程序判断需要显示的内容，或者执行对应的操作。cgi进程不断地被产生和销毁，而不会保存用户的状态。所以通常会运用会话和cookies来实现类似于交互进程全局变量（临时文件貌似会有牵连）的作用。

不过网页的显示效果比返回一个有效的字符串要复杂，混合有程序逻辑和用以显示的代码会...分离开会有很有用的分明的感觉的。比如把程序的功能逻辑分离出来，提供接口。再提供类似于GUI的模块来处理与用户之间的交互，而GUI本身显示的效果和处理的代码也有一定的分离进行。比如这样可以获得的一个好处就是，为不同的需要可以进行不同的展示，而和共用的基础代码无关。

模板并不是为了这种分离，它只是用来把服务器端执行的代码嵌入到网页代码中用于生成显示的效果。此种情况下网页的展示被作为的主题，即其效果和内容会获得更主要的关注。不过用来做以上的分离，模板是很有效的机制。

如今ROR框架的思路给Web2.0的开发很有生产力的感觉，至少是对PHP上框架的发展也有强力的影响（我承认这是新手向的分享文了，就是那种总体概览之类的感觉）。对于每个post和get有单独函数（模块）进行（对数据的，数据是框架的基础）处理，前者用于执行操作而后者用于返回结果（一个明显的区别是是否有副作用）。即使两步操作上是连续的，也可按上述区别分开进行。
路由和模型也是结构上的重要组成，补充一下。而框架的存在已不限于提供功能，而设计开发的结构和组织形式。

不过，WebApp的目的已经不仅仅是简单的提交和展示了，DesktopApp的功能可以在网络平台上实施。对于如数据库一类原本就依赖分布的App而言，两种应用之间的区别并不明显。而通过浏览器内js脚本的强大功能以及Ajax技术的运用，复杂的交互和即时的数据交换使得桌面程序的功能和CS结构的程序可以以BS或更轻便的方式实现网络应用。

插一句，发布方式也会产生变化。服务会变得更加重要，而用户看到的是展示的界面。除非是提供局域网使用的套件，版本变化比使用自动更新模块更加模糊。

简单的如计算器之类，比如不涉及文件操作，其功能与运行环境没有直接关联。运算操作在本地进行则没有与桌面应用有很大差别，当然也可以把运算放置到服务器上，仅在浏览器中进行结果的展示。（画板之类）文件操作也可网络化，有服务器进行。
CS的结构可以通过瘦客户端的形式变成WebApp，浏览器也可以当作瘦客户端来使用。整个程序有独立的客户端和服务端，是多对一的关系。两者直接有各自的代码分开执行，然后通过一定的机制相互通讯。不同的是瘦客户端会在每次使用时从网络载入，可以缓存，便于携带，也可通过一定的机制实现离线功能。把瘦客户端转变为桌面应用，以获得更高效的体验，也可编写相应程序或直接利用某平台。

一些框架有自动生成客户端脚本的功能，通常这一机制是在视图和模板这一层面上实行的。可以是逻辑流程的开发变得集中，而不必在不同的语言之间进行切换，只是分别开发了界面和流程部分的代码。和GUi的开发有一定的关联。

桌面应用和网络应用是起源于不同的需求，在设计上会有这不同的出发点和视角。而所谓云（其实就是明说不清，找了一个词）概念的使得它们之间有一定的交融，而在开发与设计上产生了共通点。好了，终于到了本文最终的主题部分了。不过感觉也说的差不多不少东西了啊。再留一点简略的在下面。

关于驱动设计的要素
从数据的创建查询更新删除的角度
从输入输出的角度（包括优先考虑交互和展示的模块）
从要执行的一系列操作的序列流程的角度
从事件（会受到的消息）的角度
还有，从是桌面还是网络应用的角度，但相比以上，这一点是次要的。

恩，以上是些废话而已。顺便再放一个设计与使用DSL的话题吧，就留这么一句。

====
091209
这是11月头写的东西，当时是想着想着就堆了写东西。恩，其实现在都怕看了。都是故意在文字上绕了很多东西。
一个http调用，包含get/post的查询和发送消息
在ajax中可以返回：text文本，html带格式文本，json/xml打包的数据，
js对视图的操作以及跨域回调相关的
这里处理session/cookies用以对客户的认证外，视图的状态保存在客户端
是返回操作还是返回数据有客户端已载入的脚本来执行操作，是两种方式。
B/S结构是依照后者的方式进行的，不过脚本也可视为数据的一种。

网络应用的最终数据存放有三个地方：本地，服务提供者，第三方空间提供者（不提供计算力）。
如果单纯是进行文件的操作，操作接口是类似的。要考虑到减少传输的问题，比如查询数据和被查询的整体数据相比就会有明显的区别。临时文件是和计算操作的的执行有紧密关联的，需要有一致的存放。不同数据存放方之间会产生公开统一的接口。

开发框架和jsGUI库，可以运算完全放在服务端，仅在浏览器中载入GUI库然后和服务器交互。这和仅在操作中进行数据传递有所区别。甚至要在服务端考虑一个用户运行多个进程(回话)的结构，来考虑服务端对状态的存储方式。参见本地程序的GUI库或框架，与网络应用是同一的。而且一些本体应用也有采用C/S结构来设计，通过命令或浏览器中的视图来传递消息或进行交互。

在补充本文的这段时间里有了GOS，让App全部以Web方式运行，技术运用html5（包括了Gear的离线运行能力）提供的网页的语义，表单和新的API。

本来上月里三篇是一个小说相关的，本帖会不协调。不过其实本帖是也同时是上上最后一天晚开始写的，所以也算对存档页的结构影响不大。我多虑了。