Managing Large Code-Behinds (Best Practice?)

[Richard Weeks]

I'm sure many Telerik users must have encountered situations where the code-behind begins to bloat to epic proportions if you have a few grids and lots of events that need to be taken care of.

For example, I have a TabStrip with 14 tabs and Telerik controls like grids and so on in every one. You can imagine how the code behind is scaling. The UI is fantastic to the end user but behind the scenes, it's all becoming dark and mysterious.

Has anyone developed a best practice in handling the ever increasing lines of code in code-behind? I'm aware of splitting the file into seperate partial files but I don't like having to edit the project file to nest those files.

I've already made as much use of the declarative syntax as I can.

Interesting topic. Regions can only take you so far when there's 1,000+ lines in your code-behind handling all those command, needdatasource, databind events, etc. ;0

Richard

[Nikita Gourme]

If I were in your shoes, I would keep the event handlers in the code-behind of those pages and will move any reusable code (public variables, methods which perform general tasks or calculate something, or any other common logic of this type) in external classes within the same project. Thus you can limit the growth of the code-behind of your pages and maintain your code base with less efforts. To simplify the management of the data access layer, you may look into using the telerik OpenAccess Orm tool.

[Richard Weeks]

It's the event handlers causing the problem. There are lots of them. We use EF4 for most of our data access these days but the events still breed like hyper-active rabbits.

Richard