zoukankan      html  css  js  c++  java
  • 阅读开发高手的代码 分享二则.NET开发框架的技巧

    阅读开发高手的代码 分享二则.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;

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

    这则技巧的实现方法是注册组件改变事件(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工具,自动完成二个配置文件的修改,即可达到零修改。而且用工具的好处是不会出错,即方便又有效率。

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

     
     
  • 相关阅读:
    class11_创建新的输出字段P2
    class10_创建新的输出字段
    class09_高级过滤数据
    Markdown高级语法
    class08_过滤数据
    class07_查询数据
    class06_插入数据
    class05_操纵表
    class04_创建表02
    class03_Create a new table by SQL
  • 原文地址:https://www.cnblogs.com/Leo_wl/p/3170965.html
Copyright © 2011-2022 走看看