By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,288 Members | 1,243 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,288 IT Pros & Developers. It's quick & easy.

Small Application Structure Help

P: n/a
After reading Extreme Programming adventures I am starting to think
more about the design of my applications. I was wondering how I would
structure a new, small VB or C#.NET Windows application.

Instead of calling a startup form I was thinking of calling a class
named after the application with a shared Sub Main and a shared member of
type ApplicationCommand. The Main routine would Application.Run the
Startup form. The startup form and all forms called from the startup form
would have access the the shared member ApplicationCommand that would
contain all the methods necessary to get the information they wanted
(ie: GetCustomerList, GetProductList, GetOrder.)

I was wondering if this is a good or bad design for a small to medium
size business app. I am not sure
anymore. I feel lost.
Questions, questions... hopefully some answers will follow.

Thanks,
CodeMonk
Nov 21 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"codemonk" <co******@verizon.net> wrote in news:#hYdmCXpEHA.3392
@TK2MSFTNGP15.phx.gbl:
The startup form and all forms called from the startup form
would have access the the shared member ApplicationCommand that would
contain all the methods necessary to get the information they wanted
(ie: GetCustomerList, GetProductList, GetOrder.)

I was wondering if this is a good or bad design for a small to medium
size business app. I am not sure
anymore. I feel lost.


I think it's a bad idea...

Your Application Class will get bloated really quickly and contain
hundreds of methods if your application grows large.

Rather, create several objects in your application such as:

Customer
GetCustomerList Function
AddCustomer Function
DeleteCustomer
etc.
etc.
Product
AddProduct
DeleteProduct
Order
OrderID Property
OrderInfo Property as DataTable?

--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/
Nov 21 '05 #2

P: n/a
Thanks for your advice. Now with that solution do I have to have members to
Customer, Product, Order, etc in each form? Do they stay alive for the life
of the form or are they created and destroyed after being called from the
form's event handler?

Which makes me also wonder about form to form communication. Does one form
call another form directly or whould you use some broker object?

Thanks again for your prompt and wise help,
Codemonk

"Lucas Tam" <RE********@rogers.com> wrote in message
news:Xn***************************@140.99.99.130.. .
"codemonk" <co******@verizon.net> wrote in news:#hYdmCXpEHA.3392
@TK2MSFTNGP15.phx.gbl:
The startup form and all forms called from the startup form
would have access the the shared member ApplicationCommand that would
contain all the methods necessary to get the information they wanted
(ie: GetCustomerList, GetProductList, GetOrder.)

I was wondering if this is a good or bad design for a small to medium
size business app. I am not sure
anymore. I feel lost.


I think it's a bad idea...

Your Application Class will get bloated really quickly and contain
hundreds of methods if your application grows large.

Rather, create several objects in your application such as:

Customer
GetCustomerList Function
AddCustomer Function
DeleteCustomer
etc.
etc.
Product
AddProduct
DeleteProduct
Order
OrderID Property
OrderInfo Property as DataTable?

--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/

Nov 21 '05 #3

P: n/a
"codemonk" <co******@verizon.net> wrote in
news:ei**************@tk2msftngp13.phx.gbl:
Thanks for your advice. Now with that solution do I have to have
members to Customer, Product, Order, etc in each form? Do they stay
alive for the life of the form or are they created and destroyed after
being called from the form's event handler?


It's up to you. You can place the objects in your Main Application form so
you don't have to create them on each for. OR, you can create these objects
on a perform basis, or you might mix and match (i.e. Product Object is in
the Main Form and shared by all objects).

To communicate between forms, either pass a reference to the form, or
declare public form properties, or you can go through a broker object.

Using a reference or public properties is probably easier.

--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/
Nov 21 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.