Click here to Skip to main content
15,891,529 members
Please Sign up or sign in to vote.
3.00/5 (2 votes)
See more:
[]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
Posted
Updated 17-Apr-11 23:30pm
v2

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
 
Share this answer
 
v5
Comments
shameen4u 24-Mar-11 1:18am    
Hello mr SAKryukov wat ever your told is correct i wanted to implement similar to MVC.I have a controller class that will return values from databse thorugh proxy.I just want to display the values in to corresponding textboxes and grid views.For that i have to create a class called presentation class and i have to assign all control values from that class.So in the form i will call only that presentation class so that i can display the data.Can you give me an example for assigning values to a controls in seperate calss?

Regards,
Shameen
Sergey Alexandrovich Kryukov 24-Mar-11 2:15am    
First, thanks for accepting my Answer.
Your approach is adequate. Your class can be a bridge between database and set of controls. You can design a class accepting, say, array of text boxes, array of grid views and some interface to database, I don't know what else... some information on keys... The class should do data-to-controls. If controls are controls, they should be editable, so sooner or later you will need controls-to-data; it should go to the same class. In this way, you leave the form class clean, just layout and other UI stuff, with data semantic abstracted out. How about time-consuming queries, etc? You also probably need a thread for data exchange...
--SA
BobJanova 18-Apr-11 7:14am    
For most simple control-related things like this you can use data binding to bind properties of the control to your intermediate ('controller', 'presenter' or, in Silverlight/WPF parlance, 'model view') class.

If you can't do that (there is complex logic in the binding, though you should try to ensure that this is not the case) then you will need to write a View class which actually does what you mention in the original question – manipulate the properties of the controls. But I stress that in almost all cases you can bypass that by data binding to the presenter class.
Sergey Alexandrovich Kryukov 18-Apr-11 16:28pm    
I agree, but in this particular discussion it can be confined to the goal of making more maintainable code, on par with good naming, re-factorization, balancing code between files, etc. Of course, if the appropriate decision on the use of this or that architectural design pattern should be made, it should come first.

Thank you for your important note.
--SA
BobJanova 18-Apr-11 7:15am    
Excellent answer SAK.
The 'poor man' answer:


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


 
Share this answer
 
v2

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900