.NET Architecture

rob_s
rob_s used Ask the Experts™
on
Hi

Currently have quite a large system in place, written in ASP, basically manages customers and jobs. System consists of over 200 ASP pages so it's fairly large.

With this design i was able to break it up into modules fairly easy.

My task now is take the application and recreate it in .NET.
I can basically rewrite as much of this as i want.

I'm basically thinking i will create a 3-tier application, with all my classes seperate from the GUI.

Ok getting to the point, the application needs to be an MDI app, but it will consist of many, many forms, is this good design, you can image with 200 asp pages their are loads of different screens, i'm going to have to replicate this somewhat, i'm just wary of having some many forms in one .exe

Is this the only way to do it???

Many Thanks
Rob
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Commented:
I presume you're not talking about ASP.net.

The .net runtime will only compile those portions of code that are actually used, i.e. JIT compilation.
If you don't like the large .exe you're likely to get, you can, and I suspect you will as per your question, create a bunch of seperate 'modules' which you can compile into DLLs.

Commented:
Best some other people comment too.
We have 3-tier application in production which has at least 100 forms.  As cuynen mentioned, we split it into multiple DLLs and a "main" exe.  The memory footprint on the client is very reasonable and the performance is good. I have no reason to believe that you'd have any problems with a 200 form app.

The only other alternative I can think of is to split your app into multiple exe's.  The issue then becomes how do you share context between them, and the only answers I know of is either some type of "common" data store on the client or use something like .NET remoting (on the client) and run some or all of your forms as separate objects.  My gut feeling is that its not worth the hassle.

By the way, unless somebody else comes up with something snazzier, give the points to cuynen - his answer is correct and he got there first.
Learn Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

Commented:
Hmmm, I would like to ask why you would need 200 forms in the first place?

It would seem to me that you'd be better off to create more generic forms and possibly some inheriting forms which would use windows controls contextually to provide you with the functionality currently supplied by your 200 ASP pages.

Although you'd end up creating a number of controls and you might argue that it wasn't solving the problem of 'many forms', but only moving it to the converse problem of 'many controls', you'd probably find some similarity in a number of the controls and by coding the controls carefully (using inheritence/polymorphism etc.) should find that you only need a handful.

I always ask myself, albeit shamedfacedly, how would MS do the GUI I'm working on, and having never seen a 200 form MS application, I have to say it sounds like you could factor out some of those puppies

U

Commented:
Hmmm, I would like to ask why you would need 200 forms in the first place?

It would seem to me that you'd be better off to create more generic forms and possibly some inheriting forms which would use windows controls contextually to provide you with the functionality currently supplied by your 200 ASP pages.

Although you'd end up creating a number of controls and you might argue that it wasn't solving the problem of 'many forms', but only moving it to the converse problem of 'many controls', you'd probably find some similarity in a number of the controls and by coding the controls carefully (using inheritence/polymorphism etc.) should find that you only need a handful.

I always ask myself, albeit shamedfacedly, how would MS do the GUI I'm working on, and having never seen a 200 form MS application, I have to say it sounds like you could factor out some of those puppies

U

Commented:
Hmmm, I would like to ask why you would need 200 forms in the first place?

It would seem to me that you'd be better off to create more generic forms and possibly some inheriting forms which would use windows controls contextually to provide you with the functionality currently supplied by your 200 ASP pages.

Although you'd end up creating a number of controls and you might argue that it wasn't solving the problem of 'many forms', but only moving it to the converse problem of 'many controls', you'd probably find some similarity in a number of the controls and by coding the controls carefully (using inheritence/polymorphism etc.) should find that you only need a handful.

I always ask myself, albeit shamedfacedly, how would MS do the GUI I'm working on, and having never seen a 200 form MS application, I have to say it sounds like you could factor out some of those puppies

U
Yes, create the client such that it contains only the "bare essentials". The whole concept of MSIL is that instead of getting a large compiled EXE you get a tiny stub.

If you have to create a heap of forms, put them in a separate project and compile to a DLL which I think can reside on a central server. Perhaps group the forms logically by business function and create the projects accordingly.

I must say though, 100+ forms sounds just a bit excessive!

Create base classes and use visual form inheritance where possible.

Perhaps create a FormBuilder module that can use a base form and dynamically build the rest at runtime.

Commented:
To offer an alternative to the remoting option presented previously, multiple application domains could also be used if you want to have separate exe's in one physical process. Not the way I would go.

200 forms doesn't sound bad to me, but a way to reduce the number of forms would be the .NET equivalent to ActiveX controls: User Controls. That will allow you to build pieces that forms have in common separately and the just reuse those pieces on each of the many forms that require it. This works well when combined with form inheritance.

You may also want to investigate implementing some of the design patterns to simplify your solution. For example, you can generate your form instances from a Factory (choose an appropriate factory pattern; there are other patterns too, don't get stuck on this one!) which you can place in a seperate DLL. Then your application logic will be separate from your GUIs and in most cases you can even hide the forms' implementation details.

For example (simplified):

UserDetailsForm frmUD = GUIFactory.GetUserDetailsForm();
UserDetails ud = frmUD.ShowGUI();
MessageBox.Show(us.ToString());

The above could then become:
// ...
UserDetails ud = UI.GetUserDetails();
// ...

with the form hidden within the "GetUserDetails" method so that you can concentrate on the data it manipulates in stead of how it does that (through a form being displayed to the user in this case).

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial