.NET分布式部件的chunky界面

chunky界面对一些人也许是一个新的概念，但是如果你在不久之后计划要开发分布式.NET 应用软件，chunkiness是一个你需要熟悉的理念。这篇文章中，我将阐述这个理念之后的基本内容（他针对的是传统的面向对象设计学说）并讲解为什么chunkiness会是我们所需要的方式。

什么是chunky？

基本上讲，chunky界面就是一个利用最小数量的对象方式调用来完成最大数量的工作的界面。通过例子的形式，我们先来看看传统上来讲是如何在VB6中创建一个COM对象的：

Dim o as new SomeObject
o.SomeProperty = “Some value”
o.SomeOtherProperty = “Some other value”

使用这样的一个微粒界面来给SomeObject设置初始值是绝对没有错误的（而且确实没有使用COM的替代）。这就是说，直到你试图对基于服务器的对象使用类似的方法：在SomeObject驻留在远程服务器的分布式系统中，你都要进行三次工作—一个是创建对象，另两个是设置两个属性。有了使用参数化构造器的.NET类，下面的代码(VB.NET)将会更加地高效：

Dim o as SomeObject
o = new SomeObject(“Some value”, “Some other value”)

面对惯例

我并不是说优秀的J2EE开发者都曾经不被人知晓。如果你看一看任一个EJB源代码，你将看到有多个构造器，每一个都带有所有类的长长的参数列表。面向对象理论者在看到这样的非微粒界面时常会因畏惧而退缩，但是关于分布式应用软件开发的事实是对一个服务器主持的对象的调用经常是造成大多数性能瓶颈的来源。较少的方式调用就意味着较少的与服务器的往返，而除非你和应用软件服务器之间有dedicated T-1的话，这将给你的使用者带来更佳的性能。

State与chunky

给你的界面“chunk-ifying”的理念正好与建构stateless部件的理念相吻合。Stateless对象在方式调用之间并不保持任何内部数据。Stateless对象对于分布式应用软件是很理想的，这是由于在其他条件都相同的情况下，他们比stateful对象消耗更少的服务器资源。

问题在于stateless对象非常难以恢复正常，特别是那些开发者用来创建类似于COM部件的stateful对象的。在一个chunky界面中，每一个方式调用都拥有基本信息，而不是使用前一个调用的数据（这个调用可能来自另一时间）。Chunky界面使得stateless编程变得容易非常容易。

不只是构造器

好的，建构Chunky界面重要的一步就是使用参数化的构造器，但并不仅仅是这样：你需要逻辑性思考你要如何使用你的对象，将相关的单一方式组合成接受所有方式参数的大型的“后方式”。你还应该看一看关于更新对象私有域的单一重载方式。

例如，如果一个对象的内部数据经常在更新之后刷新，将刷新作为更新方式的逻辑的一部分，或是给出一个替代的“更新和刷新”方式。而如果你面对的是一个预先存在的界面或是一个在本地和远程都可以使用的界面，那么通常你可以使用后面的方法。

作为一个我认为可以是chunky界面的完美体现的实例，我们来看看SQL。假设说，你想要在sometable之中找到记录，而sometable中fielda的内容是“搜索值”。下面的SQL声明提供了一个从数据库服务器取回数据的简洁的途径：

SELECT * FROM sometable WHERE fielda = ‘search value’;

现在想想在没有SQL查询的情况下完成同样的事情你需要的代码（和服务器指针的往返）的数量。假定一个类似ADO的句法，你需要如下内容：

Do
If rs.Fields(“fielda”) = “search value” then
Found = true
Else
rs.MoveNext()
End If
Loop Until Found

不用考虑到这种情况下fielda中包含有多个我们需要的记录，你就绝对会因为它的性能表现而发疯。而为什么你的分布式.NET部件也以这种方式建构呢？