类实现背后的代码 [英] Code behind class implementation

查看:55
本文介绍了类实现背后的代码的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

[ ]大家好,

我对类后面的代码有疑问.我有3种形式,其中包含文本框,gridview,comboboxes.我要做的是我不希望在form中进行任何编码.因此,我需要调用类,并且我需要将所有形式的控件放入该类中,我需要在该类中分配控件的值.任何人都可以帮助我.等待您的答复.

问候,
Shameen

[]Hello All,

I have got a doubt about code behind class.I have 3 forms and that contains text boxes,gridview,comboboxes.What i have to do is i dont want any more coding in forms.so i need to call a class and i need to get every controls of my form in to that class and i need to assign values of controls in that class.Any one can help me out.waiting for your reply.

Regards,
Shameen

推荐答案

问题很模糊,但我会尝试提出一些想法.

我认为您没有正确解释您的想法.您说:我不希望在表单中进行任何模式编码".看来您想要将UI与特定于应用程序的功能隔离开来,这将是最好的选择.但是在下一句话中,您说您想在单独的类中使用表单控件.是的,您可以,但是会有很大的改善吗?

我觉得您的表单问题不是表单编码,而是与表单编码在同一文件中.想一想.这是一个好主意.表单被自动生成的代码污染.因此,我有以下想法供您考虑:

1)继续在表单类中使用表单控件:它们在其中.但是,从模板将Visual Studio创建的文件中与表单相关的代码隔离开来.注意:表单类是使用部分类声明在两个文件中生成的.每个表单创建更多文件,每个UI功能方面创建一个文件.注意:对于局部声明,您不必重复继承列表.这非常好:如果您需要更改基类,则只需在一个文件中进行操作.此外,您可以将接口添加到单独文件中单独的部分声明中.您可以将接口实现保存在一个文件中,然后将其与其他文件分开.良好的界面之间可以在表单之间进行通信. (从另一方面来说,避免使用多种形式;一个主要形式最适合应用程序;使用制表符UI或类似的方式)每个方面都有单独的部分声明的文件.

2)另外(但不能代替上面的内容),创建与表单控件一起使用的类.这实际上是您的想法;我只想提出以下几点:使它们形成不可知论.例如,控制人口.如果总体(更确切地说是数据到控件和控件到数据)很复杂,请为此创建一个实用程序类.班级应该对表格一无所知.它应该收到控件列表并与它们一起使用.有许多类似的任务可以很好地与表格隔离.这将有助于保持表格清洁.

3)不要使用Designer添加任何事件处理程序.仅用于布局.过多的自动生成的代码很难支持.首选手动代码来处理事件.无论如何,处理本质上不是视觉的.另外,您可以使用匿名委托. Designer生成的代码过时,难以支持,甚至违反了Microsoft命名约定.

4)尽最大可能将特定于应用程序的代码和高度通用的代码(例如算法)与UI隔离.尝试学习和分析以下架构设计模式的适用性:MVVM( http://en.wikipedia.org/wiki/Model_View_ViewModel [ ^ ]),MVC( http://en.wikipedia.org/wiki/Model-view-presenter [
The question is very vague, but I''ll try to give some ideas.

I don''t think you correctly explain you idea. You say: "I don''t want any mode coding in forms". It looks like you want to isolate UI from application-specific functionality, which would be the best thing to do. But in next sentence you say that you want to work with form controls in a separate classes. Yes, you can, but will it be a great improvement?

I feel that your problem with forms is not coding in form, but coding in the same files as forms. Think about it. And this is a good idea. Forms are contaminated with the auto-generated code. So, I have the following ideas for your consideration:

1) Keep working with form controls in form classes: there is where they belong. However, isolate your form-related code from the files created by Visual Studio from the template. Pay attention: form class is generated in two files, using partial class declaration. Created more files per form, one per a UI functional aspect. Pay attention: for partial declaration, you don''t have to repeat inheritance list. This is very good: should you need to change base class, you will do it only in one file. Moreover, you can add interfaces to your separate partial declaration in a separate file. You can keep interface implementation in one file and separate it from others. Interfaces a good to communicate between forms. (From the other hand, avoid multiple forms; one main form is the best for application; use tabbing UI instead, or something similar) A file with a separate partial declaration per aspect.

2) Additionally (but not in replacement of the above), create classes working with form controls. This is actually your idea; I only want to make the following point: make them form agnostic. For example, population of control. If the population (more exactly, data-to-controls and controls-to-data) is complex, make a utility class for that. The class should know nothing about the form; it should receive a list of controls and work with them. There are many similar task which can be nicely isolated from a form. It will help to keep form clean.

3) Do not add any event handlers using Designer. Use it for layout only. Excessive auto-generated code is hard to support. Prefer manual code for handling event. Anyway, handling is not visual by its nature. Also, you can use anonymous delegates. The code generated by Designer is archaic, hard to support and even violates Microsoft naming conventions.

4) Do your best to isolate both application-specific and highly universal code (such as algorithms) from UI. Try to learn and analyze applicability of the following architectural design patterns: MVVM (http://en.wikipedia.org/wiki/Model_View_ViewModel[^]), MVC (http://en.wikipedia.org/wiki/Model-view-controller[^]) and MVP (http://en.wikipedia.org/wiki/Model-view-presenter[^]).

—SA


穷人"的答案:

The ''poor man'' answer:


如果您没有这样做的理由,那么请不要这样做!



If you haven''t a compelling reason for doing that, then don''t do that!


这篇关于类实现背后的代码的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆