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.
Related
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.
I've used MVC before and really like the way it is organized but at times I have to go back to working on ASP.net Webform applications and really wonder what the best way to organize the code is.
Does anyone know of resources that deal with just that? I am pretty familiar with C# but would like to gain further insight.
An example would be a news article portion of a website.
You'd have a web form to display the data to users and then one for administrators to post the articles. Do you simply do everything in the code behind or do you farm it out to another controller-like class you've created?
Break the logical components into separate modules, which could mean separate namespaces; so you might end up with separate assemblies as well.
You cannot code everything into the code-behind; especially if you are doing a large project. All you need to do is to decide on the data exchange contract between modules, or layers. You should clearly specify the module1 guy that you will need a method Foo(param1, param2, param2):bool, and you expect it to translate news into another language.
Having seen several different ways of setting up larger projects in flex, I'm wondering what your opinions are of how to organize projects that are going to require 2 or more different applications. For example a public and private site within the project.
The two main ways that I know of would be first, creating one flex project, and then adding different mxml application files. Both applications would be able to share code.
The other way (which I currently like, but have no way of justifying), would be to create a different flex project for each application, and any code that needs to be shared could be part of a shared flex library. I guess something about the separation of the applications I like more, especially since I'm either working on one or the other at a time.
What are your opinions, and do you have any reasons for doing it one way or the other?
I recommend the library approach. That said, you can still use multiple applications in one workspace (and I do), but it's handy to keep the "one project, one application" rule. My workspace might have 5 projects, each of which has an MXML application, and 4 library projects, which have none.
I have used common library approach, it gives more decoupled code. Common library can also be used by some other projects later. Two applications in one project are mix and poor organisation for me.
One project with per application. I agree with everyone else. I would add that common libs are a good way to go as well. If you are working for a client that is having you build 2 or 10 applications then you will for sure want to reuse features as you are likely going to do this to save time and also so that the applications share common themes and functionality.
I find that a good rule to follow is if you tend to use a feature more than two or three times then it is a good candidate to be placed in a common lib.
I usually structure my projects by features. and example would be something like ... take an MP3 player application.
I would have the following packages
com.yourdomain.applicationname.mp3controls
com.yourdomain.applicationname.albumlistings
each feature would contain commands, model, view packages to start.
then maybe you find that you really like the mp3controls feature and you can use it on some other apps like say a video player application. The mp3controls could then be put into a common lib and then maybe renamed to something like "mediacontrols" or something.
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.