标签:Designs-Cavingdeep的.NET专栏

统一界面设计

想像如果我们可以用设计Web页面的方式去设计Windows（Linux、Unix，任何你可以想像到的图形化操作系统）界面那会是什么样子的？我们将可以统一界面设计，我们可以将可以跨平台设计界面。

我们都知道Web就是这样做的，为了让全世界的人能够在不同的地方不同的操作系统下看到同样的界面，W3C推出了一系列的标准：HTML、CSS、DOM等等，如果一个Web浏览器完全符合标准的话那么我们在世界的每一个角落看到的网页将都是相同的。同样Java下的Swing也有同样的目标，为不同的平台提供同样的界面与设计方式。但是它们都有一个很大的缺点（或不足），那就是它们的设计方式还不够好，没有将界面设计的要领规划分类、使界面的设计成为一种很漫长的过程。什么意思呢？让我们来看看，做界面的需求不外乎以下几大类：

元素：界面上可以有的界面元素，如Button、TextBox、图片、文字等。
排版：界面元素的位置以及元素间位置的关系。
样式：元素的大小、颜色等装饰性的特性。
文化：多国语言、语言间差异性的处理等。
文件模型：将界面通过一个模型来展现，通过文件模型与UI脚本可以动态地定义界面。
UI脚本：用来控制文件模型好实现一些动态效果，如动画等。

现在的问题是HTML、Swing、System.Windows.Forms等（对Avalon不是很熟悉，略微看了一下，不是特别强）都没有将这几种需求分开处理，而是混合在了一起，这样设计出来的界面就很死板，再想改界面的时候就会发现很麻烦。但是注意现在W3C已经开始推荐XHTML+CSS来实现界面设计了，也就是说，它将元素与样式分隔开了，但是排版与元素还没有完全分隔开，还是需要DIV元素来做排版，而且由于XHTML的性质没有做到文化处理。

现在想像一下，如果我们可以使用一种类似XHTML 1.1的基于XML的语言来定义界面元素，用类似CSS的语言来定义样式，用自创的方便排版的语言来定义排版信息，再用资源文件+自定义文化语言来定义文化的话我们能实现什么效果呢？答案当然是所有我们上面所谈过的了，统一的、跨平台的、支持多国语言的、动态的、样式可替换的（不仅仅是皮肤的功能）并且可多次转换（因为基于XML）的界面定义。Cool, no?

当然这些都只是一些构想，实现它们需要相当的时间，而且也需要一定推广，不过我相信有朝一日当W3C等标准化组织推出相关标准后这一切就都会变成可能了。目前，我们还是可以利用一部分概念小面积的改善我们项目中的UI设计体验！

posted on 2005-04-29 14:18:00 by cavingdeep 评论(2) 阅读(5566)

AOP在.NET中的现实

因为最近关注AOP的人越来越多，所以就阅读了一些关于AOP方面的文章，一篇个人认为比较好的文章是我在CSDN上看到的转载的一篇文章，转载者没有注明出处是哪里，所以我只好将转载网址贴在这里了《AOP及其Java实现机制》。如果您还没有听说过AOP或者还不怎么了解，欢迎首先阅读转载文章然后再继续这篇Blog。

由于目前我对Java的了解不是非常丰富，所以就不对Java方面的AOP作出评论了，但就.NET而言，我觉得AOP在.NET中的实现还是有一定的不理想因素的。

AOP思想

AOP的基本思想是将不同方面（Aspect）的代码分别开来写，达到逻辑清晰，可复用的目的。与OOP不同，AOP的核心是关注点（Concern），它将程序分为核心关注点（业务）与横切关注点（可能有纠结的功能，例如日志、事务等）。AOP并不与OOP冲突，OOP是AOP中实现业务的手段，我们主要用OOP来做核心关注点与横切关注点的实现，然后用AOP将这两种关注点合并产出最终程序。

AOP的实现

目前，AOP会通过织入器（Weaver）将不同方面的代码混合（织入），织入的方式多种多样，一般来说，只要是能够将两段毫不相干的代码混合在一起，那么就可以叫做织入了。不过，目前大多数产品的做法是采用反射、动态代理、元数据等方法来作为AOP的织入方法。我在下面要讲的，就是反驳大多数采用动态代理来作为AOP织入机制的产品，也就是我前面说到的AOP目前来说，至少在.NET中，还是不太理想的。

Aspect#

在.NET下也有不少的AOP框架，其中比较有名的当数Aspect#，但是我在对它进行了一定的使用测试后，发现了至少对我来说，它丝毫没有用处。它的实现机制就是大名鼎鼎的动态代理与反射。对于还不熟悉动态代理的朋友，它说白了就是“代理”模式的动态形态，可以动态的生成某个类的代理。至于代理模式，就是GoF中著名的23个设计模式之一的代理模式，还不明白的朋友赶快翻阅一下《Java与模式》吧！^_^

AOP中的代理模式

你也许会问，我到底对动态代理有什么不满呢？没有，我对动态代理没什么不满，如果使用正确的话，动态代理还是很有价值的。不过，要想作为AOP的万能织入器的其中一种，动态代理就不是那么可靠了。熟悉代理模式的朋友一定都知道代理模式是靠继承（或对“基接口”的实现）实现代理的，那么如果一个类不可以被继承呢？Bingo，这时代理模式就不成立了，也就是说，如果你用Aspect#对一个sealed类进行Mixin的话（混合以便动态增添新功能）那么它就会失败，因为无法创建动态代理。这到底是怎么回事呢？让我们来看看代理模式（在这里更准确的说应该是装饰模式）是如何做到织入新代码的：

public class A ...{
   public A() ...{}
}

public interface ILog ...{
   void Log();
}

public class ProxyForA : A, ILog ...{
   public ProxyForA() ...{}

   void ILog.Log() ...{
      //......
   }
}

A a = new ProxyForA();
ILog log = (ILog) a;
log.Log();

就像你看到的上面的代码，动态代理会动态的生成这个Proxy类，并且通过一个Wrapper来将它返回，作为一个A看待，这时看不到ProxyForA存在的你可能会认为真的很神奇，将A的行为扩展了，但当A是sealed类时利用动态代理的弊端就暴露了，因为A是不可以被继承的。这也从另一面证实了一个OO设计原则的重要性：DIP（Dependence Inversion Principle），这个原则基本上告诉我们要以抽象概念做设计，不是以具体，这样，我们就永远都有可能使用代理模式了。关于OO设计原则，我在CSDN上的Blog有一篇总结它们的文章，感兴趣的朋友可以参阅一下^_^

那么现在让我们来看看AOP中的另一个织入手段，拦截器（Interceptor）。拦截器可以根据一个或多个切入点找到要切入的代码部分然后将横切方面（日志、事务等）代码织入，这个织入手段同Mixin一样，本身没有什么问题，问题出在在Aspect#中也是通过代理来实现织入的，这样就又带来了一个新的问题，什么问题呢？虽然目前.NET下AOP框架产品对于切入点的支持不是很广泛，但这也只是迟早的事，问题还是没有的，真正的问题就出在使用代理模式上面，让我们来看看如何通过代理模式在已有的类成员中实现织入：

public class A ...{
   public virtual void Do() ...{
      //....
   }
}

public class ProxyForA : A ...{
   private IInterceptor _interceptor = new LogInterceptor();

   public ProxyForA() ...{
      _interceptor.Instance = this;
   }

   public override void Do() ...{
      bool proceed = _interceptor.Intercept();
      if (proceed) ...{
         base.Do();
      }
   }
}

使用动态代理实现切入点的织入就是以以上方式实现的，可以很清楚的看到，这只在A类中的Do方法为virtual时才可以实现，如果某个要切入的成员不是virtual，那么织入就会失败。

总结

以上所谈到的两个使用动态代理的缺陷都是很严重的，如果非要改动代码来适应动态代理的话就会破坏面向对象的设计，严重的甚至可以带来安全隐患。

正因为上述原因，我觉得Aspect#不是一个很理想的产品。个人觉得一种较好的AOP织入实现方式是代码在编译前的替换，这样可以避免所有限制与问题，但缺点是非常难实现。目前我觉得使用AOP框架倒不如自己的好设计，如果设计的得体，那么同样可以后期通过代理、装饰等模式对系统的行为进行快速方便的扩展。同时我也很期待新的技术的出现来使AOP成为现实！

posted on 2005-03-28 17:17:00 by cavingdeep 评论(13) 阅读(7574)

Cavingdeep的.NET专栏

导航

关于

标签

每月存档

最新留言

广告

统一界面设计

AOP在.NET中的现实