Need help with a large ASP.NET application

Question

Hi,

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

Answer 1

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).

Answer 2

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.

Answer 3

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.