rob_s
asked on
.NET Architecture
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Best some other people comment too.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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
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
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
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
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
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.
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.
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.GetUserDetailsF orm();
UserDetails ud = frmUD.ShowGUI();
MessageBox.Show(us.ToStrin g());
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).
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.GetUserDetailsF
UserDetails ud = frmUD.ShowGUI();
MessageBox.Show(us.ToStrin
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).