beginner question: when to create a class

[babsjoy]

I am a beginner a ASP.NET currently a COBOL programmer. I am not sure I understand why custom classes need to be created. Is there some sort of criteria that determines why a class should be created instead of just coding all the logic in the form's code behind. Does creating class make the code and logic easier to understand ? I am currently working on a ASP.NET project at work. I have all the code working (in the code behind of the form) to SELECT, ADD, and UPDATE a person using a stored procedure but now other experienced programmers are telling me I should create classes for these actions. Can you explain why ? Thanks in advance...

 

[Custom24]

Good question.
Your program works. That's fine, and one option is leave it alone.
However, there are a couple of scenarios I can think of where using custom classes might help.
1. The project evolves to use other types of applications apart from web forms, for example windows forms, web services, windows services. If you have all the logic encapsulated in properly decoupled classes, using the same classes in the new application will be easier, and might not require any alteration to the code in the classes.
2. In six months, another developer gets put on the project, and has to review the code or alter it. Again, if the logic is separated so that presentation logic is in the form's code behind, and data access or business logic is in classes, then their job will be easier. That developer could just be you returning to the project having worked on something else.

I'm not a complete convert to OO just yet - the way I see it, the most important thing is that at the end of the day, the job has to get done. If you have to break a few encapsulation rules to do it, then hey. But the next project will be better for whatever attempts you do make to do OO in this one.

Hope this is of some use to you.

Mark

 

[jasonsalas]

Marks gave some good tips. If your current project is part of a much larger, complex project, rolling your own custom class might be advantageous because, as Mark so elegantly points out, other developers will be able view/modify it better if its centralized, other than hunting it down in files.

Using a custom object through instantiating a class of your own design also provides better code reusability throughout your app. But then again, if this is a singe-shot use, this might be overkill.

In general, rolling custom classes into seperate files **may not** result in better performance than coding directly (that you're using SPROCs is the best performance gain), but it's better for larger apps where the code is accessed in multiple places.

If you're doing true n-tier development, it'll be better for maintenance somewhere down the road if you seperate your functional/custom code into a seperate module. It makes for better maintainability, needing to change code that's referenced in multiple places throughout your Web app in one single locale.

Keep in mind that the choice to use a custom class or not (or use code behind) may also be behavioral rather than performance-based. Some people like code behind when working alone, some people don't. It's obviously better for larger organizations because UI designers can work on the controls and HTML and the programmers can mess with the script code and both are at peace.

EXAMPLE:
=========
I personally use code behind when working on WebForms that are very complex or have a LOT of code, such as pages using DataGrids. Things like paging, sorting, in-line editing and adding records makes for a lot of code, so in this case I seperate things.

I also roll my own custom class when working on a project wherein a method is called by two or more WebForms, attaining the aforementioned benefit of centralization.

Sorry...sorta long-winded, but hope this helps you out.

Jas