阅读开发高手的代码分享二则.NET开发框架的技巧

最近阅读了一套ERP开发框架的源代码，对开发框架的理解又深入一层，也为其将知识点运用的如此灵活而自叹不如。

郎咸平教授说，国际金融炒家对国际金融知识的理解与运用程序，是不可想像的。1997年的亚洲金融危机，国际金融炒家对香港的攻击是卖空港币，但是最后却反应到股票市场，惨败。同理，开发高手将系统的知识点，运用的相当灵活，你完全没有想过可以按这种方式做出程序，灵活简便，维护方便。

1 .NET组件自动重命名

在Windows Forms开发，经常遇到一件头疼的事情是一个Form界面有很多控件，而这些控件的名称(Name)很难维持命名统一。比如，开发规范里面说，要给所有的Button命名为以btn开发。如果界面中有二个按钮，确定和取消，那么可以按照规范，为之命名为btnOK,btnCancel。再扩展到其它的控件，都应该遵守这样的前缀命名法。

经过整理，形成下面的表格规范

控件	前缀	举例
Button	btn	btnOK
ListView	lst	lstProject
Label	lbl	lblUserName
Combox	cmb	cmbProjectType
TextBox	txt	txtUserId
CheckBox	chk	chkEnable
GridView	grid	gridProduct

当一个页面中有很多控件时，如何保证控件命名，还是这样的规范呢？

一种办法是有专门的代码检查,俗称Review，经常的花时间去改善代码，维护代码。从基本的命名上检查，修改，以符合规范。另一种方法就是我从高手的代码中学到的，解释如下。

当你给一个按钮绑定资料库字段或是修改它的Label/Text/Caption属性时，加入设计时支持，用这个名字来替换无规律的命名。比如，拖一个按钮Button控件到窗体中，它的名称是Button1, 这时修改它的Text=OK, 回车确认。这里我截获了控件的属性修改事件，于是修改控件Button1的名字为btnOK。数据绑定属性也是一样，截获绑定的数据成员的名称，再依据它来修改控件的名称，比如下面的一段代码所示

private Foundation.WinUI.Misc.Label lblDbPassword;

private Foundation.WinUI.Editors.TextEditor txtDbUser;

private Foundation.WinUI.Misc.Label lblDbUser;

private Foundation.WinUI.Editors.TextEditor txtDbDatabase;

private Foundation.WinUI.Misc.Label lblDbDatabase;

private Foundation.WinUI.Editors.TextEditor txtDbServer;

private Foundation.WinUI.Misc.Label lblDbServer;

private Foundation.WinUI.Misc.GroupBox grpConnectionParameter1;

private Foundation.WinUI.Editors.Grid grid;

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

对这些控件的名称，我没有任何的修改，只是对它绑定数据属性，框架会自动根据数据源的属性名称，进行修改，所以看起来规范程度高，完全不需要人为的来执行规范。设想一下，当系统中的窗体很多，控件数量大的时候，这种智能的命名方法是多么的有效率，将代码规范贯彻到底。

这则技巧的实现方法是注册组件改变事件(ComponentChanged)，如下面的代码所示

this.Site.GetService(typeof(IComponentChangeService)) as IComponentChangeService

2 .NET Remoting 服务器端对象自动化配置

先来看一下，基本的.NET Remoting是如何配置开发的。

先开发服务器对象，即是要暴露给客户端的对象

public class MyObject:MarshalByRefObject

    {

        public int Add(int a,int b)

        {

            return a+b;

        }

    }

服务器端把它激活，供客户端连接进来调用

[STAThread]

static void Main(string[] args)

 {

           RemotingConfiguration.Configure("RemoteServer.exe.config");

           Console.ReadLine();

 }

因为这样的代码很节省，所以还需要在配置文件中作出如下的配置

<configuration>

    <system.runtime.remoting>

        <application name="RemoteServer">

            <service>

                <wellknown type="RemoteObject.MyObject,RemoteObject" objectUri="RemoteObject.MyObject"

                    mode="Singleton" />

            </service>

            <channels>

                <channel ref="tcp" port="9999"/>

            </channels>

        </application>

    </system.runtime.remoting>

</configuration>

客户端代码，调用.NET Remoting服务

[STAThread]

static void Main(string[] args)

  {

          RemoteObject.MyObject app = (RemoteObject.MyObject)Activator.GetObject(typeof(RemoteObject.MyObject),System.Configuration.ConfigurationSettings.AppSettings["ServiceURL"]);

           Console.WriteLine(app.Add(1,2));

           Console.ReadLine();

  }

同样，还是需要作出配置才能使上面的代码生效。

<configuration>

 <appSettings>

 <add key="ServiceURL" value="tcp://localhost:9999/RemoteObject.MyObject"/>

 </appSettings>

</configuration>

我提出问题，如果要增加一个服务器端对象MyObjectB，对上面的代码，需要修改几个地方？

增加代码(服务实现和服务接口的调用)是必须的部分，不可少，另外需要修改的地方：

1 服务器端的配置文件，增加服务接口

2 客户端的配置文件，增加对服务的引用

但是，开发高手给的答案是零修改，增加一个服务，对服务端或客户端不需要作出任何的修改。

如何做到这一点呢，著名的.NET通讯组件RemObjects ，它提供了一个通用的GUI工具，用于根据服务端的接口，生成客户端的代码，依照这一点思路。我们可以考虑做一个工具。增加一个服务器端对象后，为了让它暴露出来可用，要修改的地方是两个配置文件，所以，我只需要当有新的服务器端对象要暴露出来时，运用这个GUI工具，自动完成二个配置文件的修改，即可达到零修改。而且用工具的好处是不会出错，即方便又有效率。

我以为这两个思路确实不错，能让系统的可读性增强，又提高工作效率。