Separating Javascript in Server Control

Question

I am trying to refactor my code by migrating a "Web User Control" which has become quite complex into a separate standalone "Server Control" project. Moreover, the control also has some javascript logic inside it.

So, I would like to get some advice on :

1. How and where to put (migrate) the existing javascript logic from the Web User Control?
2. How to logically and cleanly separate existing javascript for ASP.net pages? Any directory structure suggestion will be highly appreciated.

Please bear with me because I am a very beginner.

Kind Regrads

Answer 1

The answer to this question is long, complicated, and varies from case to case. Still, having worked on codebases like this, here are a few things I learned:

1. write tests: essential to any legacy codebase. you must write tests before changing your code. If it's as tightly coupled as you say then not writing tests will give you hell 2 months into the project when small side effects of your changes begin to creep into production.

2. make javascript Unobtrusive: put all javascript into .js files, away from the server and away from the structure. this way you'll have one less thing to worry about when writing your server side code.

3. divide and conquer: this is probably the best tip anyone can give you. I once worked on a project that had 5000 code line files, with html, javascript and visual basic all mixed in one ugly mess. There I learned that by extracting these mega classes into 100-line files, I could better understand the intent of each block and easily find dupes.

4. have a BA handy: sometimes a whole web page / class is so mangled that rewriting portions of it is the only way to bring it back to a maintainable state. Having someone who can explain the business logic is really important especially under these circumstances since they can tell you what a class is supposed to do, why it does it, and what parts are obsolete. In this same project I was talking about, we started rewriting certain pages. Having a BA there with us allowed us to remove around 30% of the code, since it was obsolete. having 30% work to do on a 250 thousand line codebase is really useful, especially when a deadline is looming.

5. don't use web controls, use html / jquery and handlers: asp.net web controls don't play nice with web standards. They don't play nice with ajax and the don't play nice with SPA oriented approaches. If you're refactoring towards this, replace web controls with their html input equivalents, then use javascript (jQuery, ext/sencha, dojo, etc) to add the desired behaviour. on the server you can then write handlers that can be called with AJAX.

6. you shouldn't do it alone: you should be part of a team that has an architect that sets the roadmap and patterns to use; a frontend developer that knows javascript, html, and some .Net; a backend developer that knows c# and .Net, aswell as SQL Server or the database technology and a designer that knows html5 and css, so he can propose better ways of structuring the documents.

7. you probably shouldn't be doing this at all: if you're a beginner like you say you are you should be working on properly made web projects and learning how to write correct code. I certainly don't mean to insult you, but this is a monumental task, with lots of complexities and tons of pitfalls. These projects are normally apps developed by VB6 programmers getting onto the web bandwagon as quickly as possible in the beginning of the past decade, and as a result have lots of procedural code copied and pasted into multiple classes and quirky ways to do things, as if the coder knew not much about OOP (and let's face it, most VB devs don't or didn't at least when ASP.net first came around). The person in charge should be a seasoned ASP.Net developer with solid understanding of modern web technologies and desirably experience in bringing a legacy project up to speed with the latest industry standards.