web的MVC应该比传统的MVC简单得多。

Traditional MVC involves code that "listens" for "events" so that the view can continually be updated to reflect the current state of the model. In the web paradigm however, the web server already does the listening, and the request is the event. Therefore MVC for the web need only be a specific instance of the mediator pattern: controllers mediating between views and the model. If a web framework is crafted properly, a re-usable core should probably not be more than 100 lines. That core need only implement the "page controller" paradigm but should be extensible so as to be able to support the "front controller" paradigm.

下面是我自己的框架的核心方法，它成功地应用于一家财富100强的网络硬件制造商为一家财富50强的媒体公司生产的嵌入式消费设备。我的方法被一位前Smalltalk程序员和Oreilly一本关于有史以来最杰出的Java web框架的书的作者比作Smalltalk;此外，我已经将相同的框架移植到mod_python/psp。

static function sendResponse(IBareBonesController $controller) {
  $controller->setMto($controller->applyInputToModel());
  $controller->mto->applyModelToView();
}

布尔变量只能用于布尔逻辑。在所有其他情况下，使用枚举。

布尔变量用于存储只能有两个可能值的数据。使用它们所产生的问题经常被忽视:

程序员通常不能正确地识别某些数据何时应该只有两个可能的值 指导程序员做什么的人，比如程序经理或编写程序员遵循的规范的人，通常也不能正确地识别这一点 即使一段数据被正确地识别为只有两种可能的状态，这种保证在将来也可能不成立。

在这些情况下，使用布尔变量会导致令人困惑的代码，这通常可以通过使用枚举来避免。

例子

假设一个程序员正在为一家只销售轿车和卡车的汽车经销商编写软件。程序员为他的软件开发一个全面的业务需求模型。由于知道所销售的车辆只有轿车和卡车两种类型，他正确地识别出可以在Vehicle类中使用一个布尔变量来指示车辆是轿车还是卡车。

class Vehicle {
 bool isTruck;
 ...
}

这个软件是这样写的，当isTruck为真时，车辆是一辆卡车，当isTruck为假时，车辆是一辆汽车。这是在整个代码中执行多次的简单检查。

一切都很顺利，直到有一天，汽车经销商收购了另一家同样销售摩托车的经销商。程序员必须更新软件，使其能够正确地考虑到经销商的业务发生了变化。现在它需要识别车辆是汽车、卡车还是摩托车，这是三种可能的状态。

程序员应该如何实现这一点?isTruck是一个布尔变量，所以它只能保存两种状态。他可以将其从布尔类型更改为允许多种状态的其他类型，但这将破坏现有的逻辑，并且可能无法向后兼容。从程序员的角度来看，最简单的解决方案是添加一个新变量来表示车辆是否是摩托车。

class Vehicle {
 bool isTruck;
 bool isMotorcycle;
 ...
}

代码更改后，当isTruck为真时，车辆为卡车，当isMotorcycle为真时，车辆为摩托车，当两者都为假时，车辆为汽车。

问题

这种解决方案存在两个大问题:

The programmer wants to express the type of the vehicle, which is one idea, but the solution uses two variables to do so. Someone unfamiliar with the code will have a harder time understanding the semantics of these variables than if the programmer had used just one variable that specifies the type entirely. Solving this motorcycle problem by adding a new boolean doesn't make it any easier for the programmer to deal with such situations that happen in the future. If the dealership starts selling buses, the programmer will have to repeat all these steps over again by adding yet another boolean.

软件的业务需求发生变化，要求他修改现有代码，这不是开发人员的错。但是首先使用布尔变量使得他的代码不那么灵活，也更难修改以满足未知的未来需求(不那么“适合未来”)。当他以最快的方式实现更改时，代码变得难以阅读。使用布尔变量最终是一个不成熟的优化。

解决方案

首先使用枚举就可以避免这些问题。

enum EVehicleType { Truck, Car }

class Vehicle {
 EVehicleType type;
 ...
}

为了在这种情况下容纳摩托车，程序员所要做的就是将Motorcycle添加到evhicletype中，并添加新的逻辑来处理摩托车的情况。不需要添加新的变量。现有的逻辑不应该被打乱。不熟悉代码的人也很容易理解车辆的类型是如何存储的。

悬崖笔记

不要使用只能存储两种不同状态的类型，除非您绝对确定两种状态总是足够的。如果将来可能需要两个以上的状态，则使用枚举，即使布尔值可以满足现有需求。

Tcl/Tk是有史以来最好的GUI语言/工具包组合

它可能缺少特定的小部件，外观也不如新产品好看，但它的模型很优雅，而且易于使用，因此通过交互式输入命令可以比使用可视化界面构建器更快地构建工作gui。它的表达能力是无与伦比的:其他解决方案(Gtk、Java、. net、MFC……)通常需要10到100个LOC才能得到与Tcl/Tk一行程序相同的结果。所有这些都不会牺牲可读性和稳定性。

pack [label .l -text "Hello world!"] [button .b -text "Quit" -command exit]

评论是不好的

当代码需要注释来解释它在做什么的时候，代码就太复杂了。我总是尝试编写足够不言自明的代码，不需要太多注释。

如果它不是原生的，它就不是真正的编程

根据定义，程序是由计算机运行的实体。它直接与CPU和操作系统对话。不直接与CPU和操作系统对话的代码，而是由其他直接与CPU和操作系统对话的程序运行的代码，不是程序;这是一个脚本。

在Java出现之前，这只是简单的常识，完全没有争议。突然出现了一种脚本语言，它具有足够大的功能集，可以完成以前专属于程序的任务。作为回应，微软开发了。net框架和一些在其上运行的脚本语言，并设法通过在他们的开发工具中逐渐减少对真正编程的支持，以支持。net脚本来进一步搅浑水。

尽管它可以完成许多您以前必须编写程序才能完成的事情，但任何种类的托管代码仍然是脚本，而不是编程，用它编写的“程序”确实并且总是共享脚本的性能特征:它们运行得更慢，并且比真正的(本机)程序完成相同任务所需的内存要多得多。

人们称其为编程，这是对每个人的伤害，因为他们简化了定义。这会导致整体质量下降。如果你试图让编程变得如此简单，以至于任何白痴都能做到，那么你最终会得到一大堆自以为能编程的白痴。

管理者无所不知

根据我的经验，经理通常不是通过了解代码来达到这个目的的。不管你怎么跟他们说，它太长了，不对或者太贵了。

还有一个是继第一个之后的:

没有时间把事情做对，但总有时间再做一遍

一位很好的工程师朋友曾经说过，他很生气地描述了这样一种情况:管理层把他的估计减半了，从他那里得到了一个半途而废的版本，然后给了他两倍的时间来返工，因为它失败了。在商业软件世界中，这是一件相当常见的事情。

今天在尝试配置一个只有web接口的路由器时，我想到了一个问题:

网页界面是为傻瓜准备的

上一个固件版本的CLI非常好。这个版本有一个web界面，试图从无知的IT机器人那里隐藏所有网络的复杂性，甚至不能得到正确的vlan。