I've been working with an ASP Classic site with over 500 files, some of which aren't used and some of which are; along with a database with hundreds of procs and functions and tables, in the same shape.
I need a way to get a grip on the project so I can eventually migrate it. I don't have time yet to walk through every single page and look at the SQL (stored procedures are in the database and are called properly within the ASP pages), so I'm at a loss as to how to get a handle on this.
My immediate thought is to make ASP classes and put them into the pages as I go - they'd pretty much be used for getting and setting fields, validation, and sending recordsets into display functions.
Is this a reasonable approach? Am I missing some strategy?
How would you approach this? A migration to another platform at this point is considered, but not feasible for the short term (next couple of months)
You can try to compile the project using http://aspclassiccompiler.codeplex.com/ or you can migrate to ASP.net MVC one page at a time (when needed) and using a mix of both in the meantime.
My simple advice is stop think about code. Spend more time with the UI actually using it and spend time examining in detail the database schema.
Edit
If you are trying to determine what pages are active then use IIS logging to harvest distinct pages hit. Also do some scripting to collect the names of files and text search the files in the site looking for any occurance of those files. This info should identify parts of the site that are rarely used or dead.
However in all probability there will considerable content in the "active" files which are also dead. Let me re-iterate do not actually to add classes or refactor the code at this stage you should concentrate on understanding what it does not how it does it. Understanding the DB Schema is a vital step and then understanding what UI interactions bring about specific changes in the DB.
Related
This is more of an advise / best practice question that I'm hoping someone has come across before and can give me a steer.
I need to build a web application (the client would like webforms because that's what their developers know for when i hand it over)
Essentially when the client logs in, they will pick a language then I need to replace the text for menus, input boxes etc. The client wants to add their translations and update them at any time.
Ideas I have looked at are:
Holding the translations in resource files, building an editor in to the web application and then adding attributes on the fly to my viewmodels.
Holding the translations in sql server so i have the name, language and translation as a lookup e.g. Home | French | Maison. Then on pre-render I'll scrape the screen for any controls needing translation in the menu, labels, text areas.
Does anyone know of any good examples or had the experience of doing this themselves.
I've a similar situation, and chose to store data in SQL.
Translation mistakes happen often, and you don't want to recompile or disassemble every time.
It is possible to avoid the need to republish, but I've found it just more intuitive and straightforward to maintain SQL.
Bottom line, it depends on the amount of data you have. If it's more than just a couple of keywords, it sounds like a job for SQL to me.
Edit:
In a similar question, users recommend using resources, claiming it is the standard method.
However, if your users are going to make changes to values on regular basis (not because of mistake correction, but because data actually changes), then SQL seems best fit for the job.
We have an ASP classic ERP (very large application) that we want to rewrite using ASP.NET.
I am looking for a way to organize the application so we are going to be able to separate every program / webpage (over 400) from each other. Every program needs to be independent because many developers will work on the project at the same time.
Visual Studio seems to make a DLL for every assembly so I was wondering if it’s a good idea to make a huge solution with one project per DLL.
Ex. :
Customers.aspx + Customers.aspx.vb (compiled) for presentation
Customers.DLL for the object entity
CustomersManager.DLL for business logic
CustomersData.DLL for data access
This way, we would be able to deploy every program separately without altering the others. We would also have over a thousand DLL to manage…
Does it seem to be a good solution for a large scale application?
Anyone has a better idea?
Thanks
Source control was invented exactly for the purpose of having multiple develops concurrently work on large solutions. I do appreciate the value of having components that can be deployed independently, but perhaps the value is lost as the number of independent components that require maintenance approaches the hundreds and thousands?
Separating the application into separate presentation/business logic/DAL DLLs does make sense on a per-module basis, but not usually on a per page basis.
Consider the different functional areas of your application that are likely to share code and start there (one set of projects for each).
That seems like a huge unmanageable nightmare to me.
I've been a part of several large .Net projects and the way that works the best is, like JeffN825, use some sort of source control, along with classes that support your model (database) directly.
Folders under the project root can help you split things up logically "/Customers", "/Orders", etc.
If you want to make separate projects for your classes, that is also done quite a bit. Have a separate project containing all of your database objects. Create another project for Business Logic. Actually create several Business Logic projects if you feel you need it "CustomerBO", "OrderBO", etc.
But managing over 1000 dlls and their associated web pages...that's going to be a nightmare.
I think the question was asking whether having a seperate DLL for every layer of every page was a good architecture, which it is not, if for no other reason than Visual Studio will more likely than not crawl to halt as it tries to load 100's of seperate projects (I shudder to think of what that would do, and how impossible it would be to maintain all those DLL's). Now a more reasonable solution would be to have a DLL for each layer and seperate each page's code into a different file and use a source control system. This would allow developers to share code even with the worst of breed source control systems. If your source control system has decent Branching/Merging support (i.e. not SourceSafe) like TFS, SVN, Git you don't really even after worry about people working on the same file simulatanously, and then you can organize your code by function not page. I'm hazarding to guess from the question, that there is probably an astronomical amount of duplicated code that could be simplified and made easier to maintain by breaking a rigid connection to the web code and reusing code. It can be amazing to see how much less code there will be. You can do the same on UI side with judicious use of User Controls to encapsulate shared functionality. Plus moving from ASP to .NET, you pickup things like SiteMap controls that should reduce the code footprint as well.
For many years I have had an objective of moving out of ASP/VBScript to a "better" language - my preference would be C# as I have skills in C - but I would consider other languages too (including PHP etc. so not just DotNet)
Objective is to have the code base in a language which does more for us. I hate the lack of data typing in VBScript, I would like a number of different "container objects" - rather than just a Dictionary Object, and so on - in fact I wonder why, having moved from Basic to C in the 80's, and then C++ a while after that, I managed to move "back" to Basic in to 00's.
(I could program the container objects in VBScript, but my instinct is that they would be slow in operation; we have a significant cache of "snippets" of HTML used in the rendering of the page, the ASP Application Object is a pretty blunt instrument!)
My ASP/VBScript is a single large application that is basically an "engine" to deliver web content.
It has been many years in the making, and now the ASP code changes seldom. (So I do need to justify moving it at all, or just living with VBScript "for ever")
It is driven from data in an MS SQL database.
There is only one .ASP page (made up of several include files).
Based on the query string parameters Skin and CMS templates for the page are loaded from database and suitable database Sprocs are run to acquire data which is merged into the CMS templates.
Data about the page (methods to use, etc.) is also retrieved from the database, along with details of access permissions and so on.
From what I have read some these things may make migration easier:
ASP sessions are not used - a session cookie is used to retrieve session data from the DB (so I could easily share a session half-and-half with ASPX
The VBScript uses OPTION EXPLICIT throughout, so all variables are predefined.
All output is via Response.Write (in fact most content is merged into a single variable and then output). There is no mix of HTML and <% server code %>.
I have some VBScript classes, but not many.
I have lots of VBScript functions, and a few Subroutines.
I have a test suite. This catches screen shots from the browser and graphically compares them with master images - thus I have the ability to do a regression test.
I don't have the resource to do a complete rewrite; maintenance of the existing code needs to continue during migration; but having said that 99% of our work is in CMS or SQL Sprocs, so the changes to ASP code are infrequent.
I have read of MS's utility to migrate ASP code to VB.NET. Given that my code is 100% VBScript and no mix of HTML/Script I would appreciate opinions on whether this would help me a lot or a little?
I would be happy to refactor STAYING IN VBscript with a view to making the migration to DotNet easier later on (but I'd need to know what my objectives were in doing that :) ). I could, for example, move some/all the functions to a COM object, and could probably do that piecemeal?
Thanks for your help
I have a large ASP classic intranet that I was maintaining until last year, and it was getting old, but new pieces were still being added in ASP classic because there was so much library code invested already. You already have a good setup if you are not changing the ASP code often and have some form of testing in place. (I have to admit it's the first time I have heard of the screenshot approach). If everything is driven off the DataBase and working. don't break it.
PHP will give you same problem of variant types, but will give you a world of options and choices that makes ASP classic seem like a childs toy. Out the box PHP does everything I've ever needed to do.
ASP.net is a BIG framework. Understanding it properly and fully is not an easy task, and it surprises me very often. it tries to do things for developers coming from a forms environment automatically that get very obtrusive when you come from a very precise rendering methodology like you sound you have. I found myself fighting the technology all the time, until ASP.net MVC came around. It fit my mind better because of how it worked and did what I asked it to, and nothing more. C# is an awesome language, with brilliant features and the DOT.net framework lets you do anything, if you can just find the right pieces. There is so much of it you will find yourself occasionally writing something that has been done in the framework already, only to find it just after finishing your own implementation.
Actually migrating could lead to some interesting problems. Even though you CAN run a ASP.net page much like an ASP classic page, you will loose many of the benefits of the environment as it is intended. That being said, I did do some test towards looking at migrating the site in question to ASP.net and managed to find ways around most of the stumbling blocks and reached the conclusion that such a migration would in fact be "mere work". The sheer quantity of man-hours it would take to do such a migration though made the undertaking infeasible.
Personally I would not suggest such a migration unless you have a few ASP.net projects under you belt successfully and are aware of the gotchas that asp.net brings with-it.
I have not seen the ASP to ASP.net conversion tool you speak of, but would love to get a link to it.
If you are staying in VBScript and are not aware of the AXE (ASP Xtreme Evolution) project here I can highly suggest looking into it for inspiration on getting past/around several of the ASP classic "limitations" and for the library of functionality it provides.
If you are looking for a way to justify the project to management, it will become increasingly more difficult to find classic ASP developers to continue maintaining the application. Any developer that has a choice would probably not choose to maintain an application built using VBScript. Developers that do take the job might consider it temporary and continue to look for other work.
Although I haven't heard anything from Microsoft, it can't be too many years before they decide to retire classic ASP entirely.
I've been looking into ASP.NET Dynamic Data and how it does scaffolding and routing. I've only scratched the surface, but it's looking like I'd have to create a template for each table that I didn't want to display all columns the same way.
My first impression after looking at dynamic data is that it would seem like less time on the programmer to have to edit one-time generated user controls rather than build a template for each table that doesn't have a uniform display behavior.
What proven solutions are people currently using that help ease the laborious tasks of creating ASP.NET CRUD type user controls?
Thanks
In ASP.NET webforms we use CodeSmith. From a single entity we generate admin pages, codebehinds, service layers, data layers and db stored procedures. All in a matter of seconds. I'd recommend you check it our for quickly building the crud in your apps.
We're actually working on our own code generation tool. It has already proven to work perfectly on the lower layers and now we're on the way to extend it for the presentation layer, that is for generating user controls.
I've not looked into dynamic data (although I'd like to when I have some time) but my biggest fear is always to lose flexibility. The problem is that these front-ends are then maybe generated dynamically each time based on some template and editing, especially bringing in special customer wishes becomes quite difficult. For small standard apps it may work perfectly though.
What we're therefore doing is to "generate" these usercontrols based on a set of standard custom server controls we've developed, but we'll generate just the first time from some static information about the entities in our application. Then you can continue customizing.
Such systems should help the developer, improving his development speed, doing the initial awkward work but then they should give him the flexibility to modify till the maximum. They should not add additional complexity...
I used .netTiers CodeSmith templates long time ago (years) and it was proven so strong, so, it must be more than great now.
I know a (big) company who have built a customization engine (allowing GUI for internal company options) around those templates to use them in most of their applications and were so successful.
I've used http://www.ironspeed.com/ in the past which has been great. Saved us MONTHS of time on our last project which has a big DB, so the cost is worth it. But it looks a bit ugly and can be tricky to update the DB schema once you've generated.
Obviously not much widespread use out there other than whats provided in Visual Studio.
Have a look at Blinq.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Visual studio is pretty good but doesn't create stored procedures automatically. Iron Speed designer does supposedly. But is it any good?
I have used Ironspeed extensively for the past two years for most of our ASP.NET forms over data projects.
It works. Does several things well: stored procs, fast layout of table browse and CRUD screens, fast layout of single record CRUD screens. It manages the round-trip (or half-round trip) process decently, detecting changes in your back end db schema and updating its data access layer, then making the changed columns available for you to alter your UI (in record or table control panels). ISD (as they call it) does an excellent job in making security management for your app pretty painless, even down to the control level (if you use ISD's subclassed versions of asp.net controls). Final plus, not a small one, is the CSS-based theme control (easy to change to a variety of themes, easy to customize a particular theme, and not even too bad to build your own theme variant by forking an existing one you like). Depending upon whether you let ISD create your stored procs in the code base or the database, changing DB's at run time can be a piece of cake.
Fairly active forum with a core group of helpful contributors. You can probably avoid the paid tech support through the forum.
Okay, the down sides. Creates fairly large code conglomerations, being a three tiered architecture. As Galwegian says, like any framework, you've got the velvet handcuffs (get your mind out of the gutter if you are thinking about anything other than code limitations and conventions!). The velvet handcuffs are the page and control model, the data layer, lack of a business object/class capability per se, the postback model, and the temptation to make your user GUI look like THEIR user GUI that comes out of the box because it is so darned easy and convenient.
ISD builds a basic page by combining an HTML template (in to which you place ISD specific code generation tags and any other tags, etc., you which using the ISD GUI or by hand). The page model relies upon a code behind page created from a piece of code template. The base classes are almost completely overridable, so that you can override all of the default functions, regenerate the application and not lose your overrides. The database controls live in the page container, but have their own class definitions (i.e., their code-behind) in specific /app_code files. Again, each control type has its own base class with pretty completely overridable methods. A single record control (showing a single db record) is pretty simple. A table, showing several records, has a table class and a table row class. The ISD website (www.ironspeed.com/support) has good documentation of the ISD model as a whole.
So, where are the problems in this model?
1. Easy and tempting to live with their out of the box GUI. Point ISD at your database, pick the tables you want to have it turn in to pages, tell it the kinds of pages, give it a thematic style and five minutes later you're viewing the application. Cool. But, it is very easy to forget that their user GUI is probably not what your user wants to see. So, be prepared to think for yourself and tinker with the GUI thus created. Not hard to do, and you can use VS 2005 to help you.
Business objects. You could put together your own business objects, but it would be difficult and you would get no help from ISD. ISD does a LOT of building of simple validation and checking (appropriate look up values, ranges, lengths, etc.) ISD lets you build custom queries, but these are read-only. It is smart enough (and you can override the write from a page in any case) to let you take a one to many view and write it back to the database (you'd probably override the default base method, but it isn't that hard to do). However, when you get in to serious dependency checking, ISD is still really about tables and not business objects. So, you're going to write some code.
If you are smart, you'll write it once store it in app_code somewhere and use it by calling it from an overridden method in your table or record controls. If you are like most of us, you'll first spaghetti it in to one of the code-behind classes above, and then forget you did so, or have a copy in each of the 10 pages that manipulates customer data. In my world, that has usually meant 5 identical functions and 5 that are all different (even though they are all supposed to be the same). ISD makes it tempting to order marinara, because the model lends itself to spaghetti code. Of course, you can completely prevent this, but you gotta learn the ISD model to determine the best way to do it on your project.
Page state and postbacks. Although ISD is quite open about this problem and tells users not to just take the defaults of returning the whole asp.net page state in the postback stream (cache on the server instead), the default is to return the whole page. Can make for some BIG pages. Which makes users think S L O W. As I said, you can manipulate this. But, what newbie is going to get this when it is SO tempting to just point, click, and boom - instant application. Your manager is now off your back because her product inventory table is "on the web" with a cool search and edit GUI (of 400kb state pages if you've gone a bit nuts and have just taken the default behaviors of ISD). Great in-house, but the customers in the real world....
Again, knowledge is the key. You can fix this, but you need to know you SHOULD.
Database read/write postbacks. No big problem here, but you also need to know that the model is to fetch only the data used at the moment. If your table shows 1000 records in 50 record increments, when you go from records 1 to 50 to 51 through 100, you will postback and hit the database again. This keeps data current, but increases server traffic.
Overall: Try the demo version. Point it at something simple that you really want to turn in to an asp.net application. Build maybe three tables. Then dissect it using the above as a guide. See what YOU think and post back to this question.
I have used it for convenience for a very small project. It did what I wanted and saved me a couple of days work.
The main problem I found was when it came to customising or extending the generated project. You have to spend quite a bit of time trying to understand Ironspeed's way of doing things which, I'll admit, is not my way.
I'd use it again for a small project if I knew in advance I wouldn't have to customise it much after.
If stored procedure generation is all you are after, CodeSmith is a decent option at a fraction of the cost of IronSpeed. There are several sproc templates available, and you can create your own or tweak an existing if that is what you need. You can also gen .Net code to your hearts content with CodeSmith. Tons of business class templates already exist for this.
IronSpeed's value is not in the sproc generation, but in the RAD features. I agree with #Galwegian... IronSpeed is OK for mock ups or very simple apps, not so good at all if you need to do any customization.
You may want to check out Evolutility CRUD framework. It provides some of the same features (limited to CRUD) and is open source.
IronSpeed has been great (out-of-the-box) at helping me develop data-driven corporate Intranet applications. While the code model takes a little getting used to, it is effective at maintaining a nice three-tier app. While the page templates can appear garish compared to 2010's web-design, it gets the job done, when you need function over form.
Iron Speed Designer is great for simple CRUD type web applications. You can find some useful information on our web site http://www.dotnetarchitect.co.uk/