Possible Duplicate:
What Web Application Framework for Delphi is recommended?
We have a Delphi 2007 desktop application which we have hosted using Citrix. Now we want to get rid of Citrix and somehow web-enable it.
I have done bit of research and found that it is possible by using the uniGUI.
http://www.unigui.com
Conclusion: Can be done, but would require a re-write and only a subset of components are supported. Serious questions remain are the monolithic application structure in a web environment.
There are two more options morfik and atozed and they also require a re-write.
I want to know if there is any other option which requires a very less re-write work and how fragile is it?
How fragile it is, is based on the quality of your code. If you have a good structured application, with business logic and data access fully separated from the GUI, it will be pretty safe, although you still have to rewrite mostly all your GUI.
If there's logic in your forms, and the code that talks to the GUI components is intwined with the code that checks your input and stores the data, then you have a big problem.
In that case, this is a great opportunity to refactor large portions of your app and do it better this time. ;)
Since there is no "silver bullet" here, it doesn't matter much which product you use. You have the same challenges with any of them. I would recommend spending a few days on a Proof-of-Concept (PoC) re-write of 2-3 typical screens. Implement the POC for each "finalist" product, and see how it works out. Keep track of how long it took for each one, things that were easier/harder, and how the end result appears to the end-user (performance, good/funny-looking, robustness, "feel").
As for the actual re-write, I would recommend the following:
Re-factor existing application to remove business logic from the UI.
Full Regression testing, and push that into production.
NOW proceed with conversion to one of the web tools.
Oops - I left out a step. Step 0: FREEZE all features/fixes. If fixes are needed to current production, they'll need to be done in a separate branch, and then rolled-up into this project later.
Note that this type of work lends itself nicely to outsourcing, as the work is straightforward and the requirements are simple. Especially if it can be delivered one form at a time, so progress, timelines, and $$$ can be measured in small chunks.
Another preliminary step is to develop a "cook book" for stripping the business logic from the existing GUI layer. It should identify naming conventions, common libraries (for code that should have been shared all along but wasn't), and should describe the conversion methodology.
AFAIK, there's not tool will convert your desktop application to web application without requiring rewrite for most of GUI Parts.
as Golez said, you will have to refactor your application, try to separate your business logic from the GUI, then you can use some tools like Intraweb to develop the GUI as web and reusing the existing business logic with it.
Another option by converting your application to n-tiers technology and warp your business logic as web services or any open technology and make your web part by any web languages such as ASP.Net or PHP.
Depending on how 'Web enabled' you want the App to be.. I use Cybele Software's (https://www.cybelesoft.com/) Thinfinity UI to extend Apps to the Web, including Database Apps.
It only requires the installation of their ThinFinity Server and one line of code added to the Proj source and you are in business.
The Apps all run on your PC.
Well perhaps I simplified it a little, but worth a look.
HTH.
Regards,
Ian
Related
Currently there are multiple (about 15-30) independent web applications written in another language. Each one is completely independent with files, images, headers, users, databases etc. etc. The whole 9yards, except that they all exist under the same domain and should have the same style (but they don't). They will soon be converted to C# ASP.NET MVC 2. They do share the same LDAP authentication.
The question has come up in my mind as to whether these should be setup as multiple MVC solutions or be done within a single MVC application. They will all have the same styles, mostly the same images, and it would be nice for them to share basic functions.
The reason this isn't a simple cut and dry solution to me, is that some of these applications are quite large by themselves and throwing them all together might be hard to manage. Not to mention the development of new applications will continue as well as new features added to the existing ones. Making this possibly an extremely large solution.
I am fairly new to MVC and even though I have a good understanding of it now, I'm still trying to rewire my brain here and there to work with the methodology and design.
I guess what I'm asking for, is those of you who have more experience with MVC than I do to share some incite and wisdom about MVC in practical use to give me a direction to start thinking.
Please, make yourself a favor and do not combine them in a single solution. I worked once in a project where we had one huge solution to work and that was the root of all evil. If you place everything in a single solution, you are increasing the complexity of all projects, you might be thinking, I am actually going to save a few lines of code by reusing something, but the truth is that you are creating a deadly solution which will become a bottleneck eventually
Consider the following:
The performance of Visual Studio is affected when you have more than 30-40 projects, which means that your build is going to take more and more time.
If you implement a build server (and you should) if you have one huge solution, the script to build only the projects related to each application would be really complex
Now I think you already did the most difficult part of the design when you say:
Currently there are multiple (about 15-30) independent web applications written in another language
If your applications are independent that means they have an independent domain, so there is no reason to place them in a single solution, not even treat them as modules.
Managing independent solutions does not mean that you cannot have shared components among them, (BTW when I say shared components I mean infrastructure components, please do not try to reuse domain objects).
So now the question is how should I reference the shared components?
In these days, I have found that the best way to reuse infrastructure components among solutions-projects, is by using Nugets. Using Nugets makes it easy to distribute new version of the components, so my suggestion is: create a private Nuget server in your organization (a simple IIS application) and add to this server your own private packages and just reference them from your solutions
You can place in your Nuget packages practically anything you need including:
Assemblies
XML config files (including common XML logger configuration files)
Common JavaScript files
Common Style Sheets files
etc...
This is a good article to create a private Nuget repository
http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds
To create a Nuget:
http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package
And finally to integrate the creation of a Nuget in your CI server:
http://www.hanselman.com/blog/NuGetForTheEnterpriseNuGetInAContinuousIntegrationAutomatedBuildSystem.aspx
http://docs.nuget.org/docs/reference/command-line-reference
When I go for combining multiple web applications into single.. I'll consider the below points.
If all the applications shares a common business model.
If they shares a common infrastructure (security, validation, logging and others..)
If they shares same a common user base.
If combining multiple projects into one helps me to reduce the cost of maintenance and enhancement.
In your case you said each one of them is completely independent then why you need to combine?
My recomendation is DI and create each proyect like a plug-in ,so each proyect can be developed or manage in separate without affect others
I have a few proyects with MEF and it's so easy create new or manage existents plug-ins
Here is a getting started MVC and MEF… http://blog.maartenballiauw.be/post/2009/04/21/ASPNET-MVC-and-the-Managed-Extensibility-Framework-%28MEF%29.aspx
and a downloadable example http://www.hanselman.com/blog/ExtendingNerdDinnerAddingMEFAndPluginsToASPNETMVC.aspx
The same style could be accomplished with a unified stylesheet referenced by all, as long as you use similar mark-up in your pages within the apps. Common functionality could be provided through a unified class library. To me, it really depends on exactly how close the style and functionality are between apps... do you want the exact same markup on every page, etc.
It is common to have an instance of the Controller per application, however if you implement this using a data driven Front Controller then there only needs to be a single Class within your new WeB Application framework. So each Application might have a configuration file that maps URL to Command Class files. These can be constructed on demand or requested from a Resource Pool. A big advantage of this approach is that many of these commands would start as a very thin wrappers (ServiceToWorker) over the existing application and/or ASP views.
I totally agree with Marks answer, ask yourself "why" do you need to combine them. Do they really need to be independent?
My additional comments though are....
What you should definitely think of....
Create a unified CSS files which use the same images to be used by your applications
Write some universal JQuery (Mobile version if these are public facing) using JQuery templates/partial views as well to give all these seperate applications a unified experience
If you are not going to unify your server side code in terms of the DAL etc, then just concentrate on the client side.
Vaadin and Apache Click seem to be equally good, which one should I choose for developing my web application. Or rather, what are the Pros and Cons of each framework.
I'm a committer of Apache Click but hopefully you will find my opinion objective.
I don't know Vaadin at all, just had a cursory look at their website and examples and mission statement.
Apache Click and Vaadin are meant for different problem spaces. Apache Click is targeted at traditional enterprise web applications while Vaadin targets the Rich Internet Application (RIA) space.
Apache Click is a traditional share nothing, stateless framework. Unlike traditional action based web frameworks Click provides a slightly higher level of abstraction by using Pages and Components. At the of the day Click isn't a revolution. Its just one of many approaches of doing web application development. In my opinion its a very good approach, both from a developer and maintainer point of view. (In enterprise environments the developer and maintainer are often not the same individual, so I differentiate between the two roles).
However developers sometimes have requirements that cannot be satisfied by traditional web applications, which is where RIA comes in. They provide a richer user experience (think desktop) but this does not come for free. RIA comes at a cost in terms of complexity, productivity and time-to-market. It makes sense though, if the requirements are for a richer experience, you need to do more in order to deliver that experience.
My advice here is: think carefully about your requirements. Don't simply assume that RIA is better, there is a price to pay, so make sure you get return for your investment.
Lastly, if your requirement is for RIA, then you should compare Vaadin with Flex. If your requirement is for a more traditional web application then compare Click with Struts, Stripes, Wicket, Tapestry etc.
Kind regards
Bob
I use both ;-)
Click is the best for classic web applications (pure html with no/ small/ handmade javascript).
It is very lightweight (small size and stateless), less verbose (you can do your html in html with velocity/freemarker power ;-).
A real php-killer.
Vaadin is the best for desktop like enterprise applications.
It is statefull, heavyweight, verbose, but amazing.
Grails, Play!, Spring MVC is a real step back after Click/Vaadin.
So my advice: use both!
For most of your pages you will use Click, for complicated tasks - Vaadin.
I've been using Click since 2006. I've built various web applications with it in the last 4 years. All apps (B2B) are still going strong and continue to be maintained/added to now. The best things about Click IMO include:
Very little magic and almost no plumbing. It's all just plain java (and jsp/velocity/freemarker take your pick; or alternatively use all 3 if you so choose; I have for some scenarios because it's so easy to).
It's super fast (It doesn't mean your app won't be slow, it just means Click will never be the reason why your app is slow)
It is so easy to integrate your favourite java lib eg. Ibatis SQLMAP, Spring, displaytag, DWR etc.etc.
You don't need to buy a book to understand/use it (although you may need books for all the other 3rd part libs you plan to use).
Most of my code written 4 years ago still works with the current release. That is just awesome.
Click fits in your head. The whole framework that is. It is so simple you don't have too many questions even as a beginner.
The guys that maintain Click are super responsive and very noob friendly.
It's simplicity helps my apps adapt to new/old tech. i.e I can easily do AJAXy stuff if I want or not.
The form features make handling html forms very easy/fast.
The table features make displaying data super easy/fast
Click's features help me write apps very quickly. Makes the need for scaffolding unnecessary imo.
If you want a light weight, fast, easy to understand framework which helps you build applications as fast as you or your team are personally able to, check out click, it will be worth your while.
Before making your choice you should evaluate all options by taking them out on a test drive.
I'm not familiar with Click, and someone should correct me if I'm wrong, but I understand Click basically a technique to link your server side code to web pages. The UI is page-based and you define the UI with components corresponding to HTML elements. Ajax is not (yet) supported, I gather.
Vaadin operates at a higher level of abstraction. With Vaadin you get to concentrate on your business logic, and build your UI naturally with views, layouts and other components (check out the Sampler). You don't need to care about RPC, page transitions, HTML or templates. Vaadin gives you a fully cross-browser compliant Ajax UI that looks and works great out of the box. It's very easy to get started, and the forum is very active (>700 messages last month compared to 96 on the Click mailing list).
Disclaimer: I'm a member of the Vaadin team and have not used Click.
I would choose, and I already did in a few projects Click (over all other frameworks).
The main selling point for me was that I was able to learn Click and be quite productive in one week-end (Vaadin - but other frameworks too took me much more).
The free and available documentation for Click is much better - you can compare the sites yourself (even if the Vaadin site looks cooler, the Click site is simply more useful - at least it was for me).
The live examples are much better - I always look at them as a snippet repository, and just copy what I need from there (since I'm a lazy programmer :) ) - there's a "Page Java" and "Page HTML" link for every example that shows the source code for every available example.
Regarding the message traffic, I don't think that should be a criteria, since having so good free online docs, and the framework being so much simpler, the users simply don't need to ask that much.
Disclaimer: I'm just a simple user that have used both frameworks.
Is Apache wicket an option as well ?
My experience is with jboss/ejb/jquery, but looking at technologies for starting a new project. I've done a quick bit of research myself abd Vaadin seems to be very well regarded.
Surely Apache Wicket is something you can not ignore if you are comparing UI frameworks. ( I am doing same.) I dropped Vaadin because of poor documentation ( maybe I am not a good Googler.)
Currently comparing Wicket, Click, and ZK.
Click and Wicket are ahead so far for the following reasons:
Generates pure HTML instead of rendering UI using JavaScript which happens in GWT, Vaadin, and ZK. You can use HTML5 features then.
Even with native HTML, server-side binding of UI forms is possible.
You don't need to worry about communication with the server. ZK also does this but with their own language ZUML.
I have found server-side memory footprint higher in ZK in the case of components like the ZK Grid. (Memory footprint for Click is not known to me yet.)
This question contains a lot of background information, to make sure you fully understand why we are looking at these technologies.
The question is basically this:
For a large, spreadsheet-type, module that we need to develop for our webmodule for our application, are there any pitfalls we should know about if we decide to use Silverlight for it?
Issues we already know, and don't need any discussion/reminders about:
We're aware of the problems around using a plugin-type solution, which may or may not be installed on the users machine (and in some cases, probably can't be installed). These risks needs to be mitigated, but we're aware of them. Please don't get hung up on this.
We're a .NET company, so while ruby on rails and lots of other different platforms and architectures are good for this solution, they are not in the scope of the decision here. We have lots of code already written in .NET that we need to take advantage of, otherwise the project will never be finished regardless of platform.
Background
We have a web module for our application with employee-related information and some input forms. Our Windows desktop application is mostly a department leader type of application, to manage employees, but the web module contains mostly employee-centric functions. The web module contains mostly report-type webpages, to list information from the system, or input-forms.
The module we need to add now is more of a heavy spreadsheet type application. You change something one place, and something changes somewhere else, like sums, what is enabled/disabled, etc.
We know we can manage all of that with AJAX, but another issue here is that the application will potentially load a lot of database data in order to put the data in front of the user, and with a AJAXy solution, we're afraid that the request/response method here will have to reload quite a lot of information on every request, even to respond to seemingly easy questions.
A way to mitigate that would basically be to load information into a Session-object or similar, but that's a big no-no, so we'd rather not do that. This is a multi-user module, and some of the data is rather static, but some of the data is also going to have to be refreshed from time to time, so if 10 users loads a lot of data into the session, that's going to be a pretty big memory-hit.
We will be using ASP.NET (MVC) for this if we choose to go this route, that is, developing the module in pure HTML and similar technologies.
Then we looked at Silverlight, and would then load all the information down into the Silverlight application on the client. It would hold the current state, and would only need to touch the database to refresh some of the information, some of the time, instead, as we think the request/response model with ASP.NET (MVC) would work, on every little request.
But, since we have only done minor things with Silverlight, we're not that experienced with it, and we're afraid that some assumptions we might have, stated or unconcious, turns out to be wrong or flawed, which will make this project impossible or very hard to manage at some point.
For instance, just to take an example, is there a limit to how much memory the Silverlight application is allowed to load (I know, if I have to ask I can probably not afford it), for instance if there is a limit on 10MB, then that would be nice to know about before we're midway and start to load the really heavy data.
To make it simpler to give examples, let's just assume we're building a spreadsheet, that has so much data, that for the simple "changed a number here, what else changed", too much data from the database has to be loaded for a proper request/response model to be used, and if we move the entire thing to Silverlight, what will make that project hard or impossible?
Knowing about such things would at least give us the ability to consider if the price is acceptable.
In short, why should we not use Silverlight for this and instead go for ASP.NET (MVC)?
And again, "use Ruby on Rails instead", is not really an answer here. The options are ASP.NET (MVC) which we have experience with, or Silverlight which we don't but can gain.
Of course, if Ruby on rails, given that we'd have to start pretty much from scratch infrastructure-wise, and have to learn a new programming language, and framework, and download and learn a new IDE/tool, if it would still allow us to cut the development time in half, then please give us some information about how that might work, but I daresay that won't really happen here.
You should know that Silverlight (version 3.0) does not support any printing whatsoever, which to me sounds like a whopper of a showstopper for you (sorry, I couldn't resist). The good news is that full printing support has been added in version 4, but that is still in beta. Rumours say it should be out before the summer if everything works out according to plan, so if that fits with your roadmap I would use SL4 right from the start.
There are no memory limitations in Silverlight, but for the local storage (IsolatedStorage) mechanism there is a default limit of 1MB. But you can easily get around that by asking the users permission to increase the local storage space when he/she starts up the application. More on that here: Silverlight Tip of the Day #20 – How to Increase your Isolated Storage Quota.
(Edit)
Aside from the missing printing functionality that will be fixed in SL4 I cannot see any problems with your scenario. I would easily take the Silverlight route if I were you, especially since you already have extensive knowledge of .NET/C#.
For a rich interface as you've described, I would definately go with Silverlight or Flash rather than a html/javascript/ajax solution.
These technologies make for much better and consistent interfaces across platforms, you can buy in various components to speed things up and support things like copy-n-paste and code in a more structured way.
Another element is skills, if you have the skills to achieve it in a particular technology, then go with that.
To the answer you question the best way I can; you should not use silverlight if you decide to use flash.
HTH
What language, framework, and hosting considerations should one make before starting development of a scalable web application?
The most important consideration is not to over-engineer to the point that it gets in the way of building and launching something. Analysis paralysis is the single biggest inhibitor to productivity, progress and results.
Yes, do some planning. Pick a framework. Perfection in a framework will be impossible to find because it doesn't exist, partially because you don't know what you need until you build it anyways. Chances are, if you pick something, it will be better than picking nothing.
Yes, try to pick flexible, inter-operable tools for where you see yourself going.
Yes, look for a good built-in feature set where you see yourself going in the next 6-18 Months. Trying to look beyond that is not really realistic anyways as most projects change so much anyways going towards the first release.
So, pick what you're comfortable with or what is familiar. Don't follow the crowd, do what gets you the best results, quickest, and often. Understand that you might have to change in the future. So, whatever you build now, try to use unit testing so you can re-factor if ever needed.
If what you're building is going to be super successful, it will be a great problem to have, and an easy one to work on once it's making money as you'll be able to get other talent to help you.
Share what you end up picking and why for your situation -- it helps the us learn from you too!
Don't necessarily marry yourself to one language or framework. It may be that some parts of your site work better with different languages and frameworks than others. For example, all of 37signals' sites are based on Ruby on Rails, but they recently wrote a blog post about how the underlying technology of one is actually written in Erlang now because it's much easier to do concurrency that way.
Obviously there's a level of complexity where things turn into a mishmash, but using the right tool for the job — even if that means different tools for different jobs — can simplify things.
Firstly on language, it largely doesn't matter. PHP, Java and .Net being probably the biggest three are all proven in the sense that they run some of the largest sites on the Web so don't listen to anyone who tells you one is more suited than any of the others.
Some might also put Ruby and Django/Python in this list. I have nothing against them but I'm not aware of any big (say top 50) sites using either.
Hosting considerations depend on how low you want to start but basically the order is:
Shared;
Virtual Private Server;
Dedicated.
Scalability will largely be about your application's design than any language, framework or provider. Efficient database schema, efficient delivery and use of Javascript/CSS and in-memory caching are all issues common to any language or framework.
Language - I'd recommend something with good frameworks and good testing libraries like Perl or Java.
Framework - it depends on what do you plan to do. If you start with a hosting that does not allow FastCGI, it is best to avoid such frameworks like Catalyst or Rails. That's why I love CGI::Application (primarily Perl, but ported to other languages too) - it can run as CGI, FastCGI or mod_perl. For development it can be run from it's own web server.
Hosting - nothing is better than you own server. It can be your own server, leased server or virtual server. But you can start with cheapest hosting and when you need more, you should be able to afford it.
It depends.
Start by looking at your requirements (Functional or user defined) (Non Functional - aspects that describe your desired system link text)
Next I would clarify what it means to have a scalable web application. Define it as test cases that can be clearly tested (must support X page views / second with response time < Y seconds).
Once I had those pieces in place I would look at what type of skills my development team can support (for the intial project and on going maintenance). Then find some case studies of applications out in the wild that use similar language or framework. If someone else has made a specific language / framework scale then chances are good that you can too.
Finally go out and look for some hosting providers that support your chosen language, framework and requirements.
I've got to do some significant development in a large, old, spaghetti-ridden ASP system. I've been away from ASP for a long time, focusing my energies on Rails development.
One basic step I've taken is to refactor pages into subs and functions with meaningful names, so that at least it's easy to understand # the top of the file what's generally going on.
Is there a worthwhile MVC framework for ASP? Or a best practice at how to at least get business logic out of the views? (I remember doing a lot of includes back in the day -- is that still the way to do it?)
I'd love to get some unit testing going for business logic too, but maybe I'm asking too much?
Update:
There are over 200 ASP scripts in the project, some thousands of lines long ;) UGH!
We may opt for the "big rewrite" but until then, when I'm in changing a page, I want to spend a little extra time cleaning up the spaghetti.
Assumptions
The documentation for the Classic ASP system is rather light.
Management is not looking for a rewrite.
Since you have been doing ruby on rails, your (VB/C#) ASP.NET is passable at best.
My experience
I too inherited a classic ASP system that was slapped together willy-nilly by ex excel-vba types. There was a lot of this stuff <font size=3>crap</font> (and sometimes missing closing tags; Argggh!). Over the course of 2.5 years I added a security system, a common library, CSS+XHTML and was able to coerce the thing to validate xhtml1.1 (sans proper mime type, unfortunately) and built a fairly robust and ajaxy reporting system that's being used daily by 80 users.
I used jEdit, with cTags (as mentioned by jamting above), and a bunch of other plugins.
My Advice
Try to create a master include file from which to import all the stuff that's commonly used. Stuff like login/logout, database access, web services, javascript libs, etc.
Do use classes. They are ultra-primitive (no inheritance) but as jamting said, they can be convenient.
Indent the scripts properly.
Comment
Write an external architecture document. I personally use LyX, because it's brain-dead to produce a nicely formatted pdf, but you can use whatever you like. If you use a wiki, get the graphviz add-in installed and use it. It's super easy to make quick diagrams that can be easily modified.
Since I have no idea how substantial the enhancements need to be, I suggest having a good high-level to mid-level architecture document will be quite useful in planning the enhancements.
On the business logic unit tests, the only thing I found that works is setting up an xml-rpc listener in asp that imports the main library and exposes the functions (not subroutines though) in any of the main library's sub-includes, and then build, separately, a unit test system in a language with better support for the stuff that calls the ASP functions through xml-rpc. I use python, but I think Ruby should do the trick. (Does that make sense?). The cool thing is that the person writing the unit-test part of the software does not need to even look at the ASP code, as long as they have decent descriptions of the functions to call, so they can be someone beside you.
There is a project called aspunit at sourceforge but the last release was in 2004 and it's marked as inactive. Never used it but it's pure vbscript. A cursory look at the code tells me it looks like the authors knew what they were doing.
Finally, if you need help, I have some availability to do contract telecommuting work (maybe 8 hours/week max). Follow the link trail for contact info.
Good luck! HTH.
Since a complete rewrite of a working system can be very dangerous i can only give you a small tip: Set up exuberant tags, ctags, on your project. This way you can jump to the definition of a function and sub easy, which i think helps a lot.
On separating logic from "views". VBScript supports som kind of OO with classes. I tend to write classes which do the logic which I include on the asp-page which acts as a "view". Then i hook together the view with the class like Username: <%= MyAccount.UserName %>. The MyAccount class can also have methods like: MyAccount.Login() and so on.
Kind of primitive, but at least you can capsulate some code and hide it from the HTML.
My advice would be to carry on refactoring, classic ASP supports classes, so you should be able to move all everything but the display code into included ASP files which just contain classes.
See this article of details of moving from old fashioned asp towards ASP.NET
Refactoring ASP
Regarding a future direction, I wouldn't aim for ASP.NET web forms, instead I'd go for Microsoft's new MVC framework an add-on to of ASP.NET) It will be much simpler migrating to this from classic ASP.
I use ASPUnit for unit testing some of our classic ASP and find it to be helpful. It may be old, but so is ASP. It's simple, but it does work and you can customize or extend it if necessary.
I've also found Working Effectively with Legacy Code by Michael Feathers to be a helpful guide for finding ways to get some of that old code under test.
Include files can help as long as you keep it simple. At one point I tried creating an include for each class and that didn't work out too well. I like having a couple main includes with common business logic, and for complicated pages sometimes an include with logic for each of those pages. I suppose you could do MVC with a similar setup.
Is there any chance you could move from ASP to ASP.Net? Or are you looking at keeping it in classic ASP, but just cleaning it up. If at all possible, I would recommend moving as much as possible moving to .Net. It looks like you may be rewriting/reorganizing a lot of code anyway, so moving to .Net may not be a lot of extra effort.
Presumably someone else wrote most or all of the system that you're now maintaining. Look for the usual bad habits (repeated code, variables that are too widely scoped, nested if statements, etc.), and refactor as you would any other language. Keep an eye out for recurring things in the same file or different files and abstract them into functions.
If the code was written/maintained by various people, there might be some issues with inconsistent coding style. I find that bringing the code back into line makes it easier to see things that can be refactored.
"Thousands of lines long" makes me suspicious that there may also be situations where loosely-related things are being displayed on the same page. There again, you want to abstract them into separate subroutines.
Eventually you want to be writing objects to help encapsulate stuff like database connectivity, but it will be a while before you get there.
This is very old, but couldn't resist adding my two cents. If you must rewrite, and must continue to use classic ASP:
use JScript! much more powerful, you get inheritance, and there some good side benefits like using the same methods for server-side validation as you use for client-side
you can absolutely do MVC - I wrote an MVC framework, and it was not that many lines of code
you can also generate your model classes automatically with a bit of work. I have some code for this that worked quite well
make sure you are doing parameterized queries, and always returning disconnected recordsets
Software Development Project Management practices indicates that softwares like this are requiring to retire.
I know how hard it is to do the right thing, even more when the responsible manager knows sht and is scared of everything other than the wost way possible.
But still. It's necessary to start working on the development of a new software. It's simply impossible to maintain this one forever, and the loger they wait for retiring it the worse.
If you don't have proper specification/requirements documentation (I think no asp software in the world does, given the noobatry hability of those coders), you'll need both a group of users that know the software features and a manager to be responsible for validating the requirements. You'll need to review every feature and document its requirements.
During that process you'll go learning more about the software and its business. Once you have enough info, you can start developing a new one.