2. Limax 最大的特点

突破传统协议方式的束缚，使用View这样一个概念，应用服务器处理请求逻辑生成表现数据；客户端根据数据进行表现，大大降低逻辑处理复杂性。

协议模式的应用设计——服务器处理逻辑功能，产生输出数据，根据功能定义协议，根据协议打包数据，数据发送到客户端，客户端解码协议，根据解码数据处理后续逻辑或者直接表现数据。

服务器打包代码，通讯代码，客户端解码代码都可以根据协议描述自动生成，这看起来已经解决了很多问题。不足在哪里呢？

协议本身这个概念没有任何问题，ISO还下个7层的定义，网络上各种协议满天飞。正确设计协议才是最大的麻烦，往往是个权衡利弊不断妥协的结果。设计上最大的麻烦有两个：其一，粒度；其二，时序。

粒度——实现一个复杂应用，服务器可能有各种各样的数据需要传送，设计多少协议合适？少了，某些协议就带有冗余数据，客户端不得不根据具体上下文决定哪些数据是需要的，哪些是冗余，这就成了接收方必须处理的逻辑功能之一，这些逻辑功能与具体项目功能无甚关系，完全是额外劳动；设计多了，几十上百条协议如何维护？协议重用吧，数量看似可以减小，牵一发动全身的问题出来了，维护可能更难。

时序——实现某一功能，可能需要发送多条协议。服务器先发谁，后发谁，客户端先处理谁，后处理谁，都是需要仔细权衡的问题。为了正确处理顺序，在服务器逻辑功能的设计上有两种考虑。其一，处理过程中该发就发，问题在于，如果需要实现的是一个事务逻辑，也许后续操作导致了回滚，前面的发送显然就不应该了。其二，逻辑功能处理完成以后发送，那么就必须根据结果数据，组织一系列协议的发送，这种组织静态的还好，一旦是个动态的，处理起来就非常麻烦。服务器实现既然那么麻烦，干脆把一个功能的数据打包到一条协议好了，这下好了，同一协议的字段按何种顺序解释变成了客户端需要解决的问题，逻辑处理被推给了客户端；更进一步，服务器要求先关灯，后开灯，打包到一条协议，客户端糊涂了，到底解释成，关然后开，或者开然后关？天哪，这个责任推还推不干净。

粒度，时序，两个问题综合到一起考虑——按简化时序设计，协议粒度变粗，冗余出现了，客户端必须识别冗余，解释时序；按精细粒度设计，协议维护代价大大增加，服务器时序设计变得更加困难——原来，这是一对矛盾。

协议模式搞设计，这对矛盾不可解决，只能调和。客户端，服务器都很难避免与最终需求无关的逻辑处理，处理起来不但成本高昂，而且往往最容易出现bug。调和出来的设计，在需求发生变动的时候，非常难以维护，从一种调和方式转向另一种调和方式，也许就是伤筋动骨——最终需求无关的逻辑处理都必须挖掘出来，仔细调整，而且这些逻辑处理往往就在某一个程序员的脑子里——项目很容易被绑架。

拒绝协议模式的应用设计也就避免了调和带来的不确定性，Limax通过View这一概念，解释了数据意义上的MVC，回避了粒度问题——哪些数据改变了就发送哪些；明确了时序问题——客户端完全重现服务器对View的修改顺序。