关于基于接口的编程和Remoting技术的问题
·RG：接口是非常精致的(elegant)，但是.NET却推荐使用基于类的解决方案，这标志着接口的消亡。我们来看一看.NET remoting(远程技术)：微软提供.NET remoting用于允许在创建自己的环境中运行的对象被另一个环境访问。这意味着该对象的状态是本地的(local)，而它的行为则是远程的(remoted)。因此，remoting是一个基于接口的工具。你可以利用接口来使用.NET remoting，但是如果你阅读文档或者访问Web上的"how-to(操作指南)"，你就根本意识不到这一点。
第一点--接口消亡了
我的回应：.NET框架组件中到处都用到了接口，接口在类似VB或C#的特定的单层继承语言中特别有价值。即使最简单的String类也有IComparable、ICloneable、IConvertible和IEnumerable接口。再向前看，.NET框架组件2.0的关键的新特性--泛型(generics)--也用接口来约束数据类型。
第二点--缺少在.NET Remoting中使用接口的文档
我的回应：我决不说我们的文档是没有瑕疵的，我可以提供一个链接关于Remoting的.NET框架组件SDK示例。请注意下载的第五个示例就是在remoting中使用接口。
·RG：.NET可以使用接口(interface)，但是推荐的方法是使用类。
·RG：微软的替代作法是推荐人们使用基于类的方法，这通常会导致一些奇怪的现象出现--人们向客户端部署服务器部件，这样客户端才拥有可用的服务对象的元数据(metadata)，或者导致泡沫部件，它使哪些基于类的remoting问题四处散播。
我的回应：我们本身没有"推荐"任何机制。尽管我们可能提供了指导，但是开发者可以选择自己认为合适的方法开发应用程序。我们的模式和实践小组的确提供了这些方面的指导和最佳经验，并在如何设计远程接口中包含了向导。我看不出来我们偏好于基于类的方式，实际上，使用面向消息和服务的比使用面向对象的要增长得快一些。我承认需要把服务器部件部署到客户端上，但是不好的设计就是不好的设计，别无其它。把服务器部件部署到客户端上，使服务器对象的元数据可用，可以让人们容易地使用接口或大纲(schema)。这就是说，存在一些希望每个客户端拥有服务器代码的情形，例如对等(peer-to-peer)聊天就要求客户端同时承担客户端和服务器的角色。
关于微软在产品中使用.NET框架组件的问题
·RG：微软把.NET作为扩展自己的产品的一个有用的类库，但是到目前为止，微软却没有显示出对框架组件的更大的信心。目前只有很少的.NET产品是整个使用.NET编写的；其中一个是微软的CRM……他们不希望承担为.NET重新编写代码的开销，而且没有谁强迫他们在.NET中提供全新的代码；.NET将会被寄宿，并且在需要的时候，允许通过用户提供的代码来进行扩展。
我的回应：我们需要把Richard的话进行分解。他说微软正在使用.NET扩展已有的产品，并且微软不希望承担重新编写.NET代码的开销。为什么我们需要重新编写完美的代码呢？.NET代码可以与已有的代码交互操作，而且你也打赌说我们将利用交互操作能力层添加那些最好的受控代码提供的新特性。我前面曾经指出过，微软在所有的软件中使用了.NET，从操作系统到开发工具再到Office。
·RG：微软当前的操作
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
