Best practice - Using modal input form

[Ant]

Hi,

I'm using a modal dialog box to input data. I have created properties on the
dialog form to capture the data so that it might be read from the main form
via the dialog form. This approach encapsulates the data & I can implement
the business logic in the dialog form.

This leaves me with the quiestion. There is no Class representing the data
I'm capturing, (say, it's a customer) apart from the dialog form class. The
form now represents the customer.

Are there problems with this approach? Should I create a Class solely for
the purpose of holding the customer data & pass that to the main form via
say, a delegate, or is it ok to hold data in the forms properties.

(e.g formCustomerInput.Name).

Thanks for any thoughts on this
Cheers
Ant

[Dave Sexton]

Hi Ant,

I say go ahead and make a Customer class. After all, you'll probably be able
to use it in other places as well.

You don't need a delegate to return the Customer to the main Form, however. I
think a public property on the dialog Form will do just fine. If the user
cancels the dialog (usually by clicking the close button or a custom Cancel
button) then just return null.

--
Dave Sexton

"Ant" <An*@discussions.microsoft.comwrote in message
news:D3**********************************@microsof t.com...

Hi,

I'm using a modal dialog box to input data. I have created properties on the
dialog form to capture the data so that it might be read from the main form
via the dialog form. This approach encapsulates the data & I can implement
the business logic in the dialog form.

This leaves me with the quiestion. There is no Class representing the data
I'm capturing, (say, it's a customer) apart from the dialog form class. The
form now represents the customer.

Are there problems with this approach? Should I create a Class solely for
the purpose of holding the customer data & pass that to the main form via
say, a delegate, or is it ok to hold data in the forms properties.

(e.g formCustomerInput.Name).

Thanks for any thoughts on this
Cheers
Ant

[Ant]

Hi Dave,

Thanks very much for the advice. that sounds like the best approach to me as
well.

many thanks.

Ant

"Dave Sexton" wrote:

Hi Ant,

I say go ahead and make a Customer class. After all, you'll probably be able
to use it in other places as well.

You don't need a delegate to return the Customer to the main Form, however. I
think a public property on the dialog Form will do just fine. If the user
cancels the dialog (usually by clicking the close button or a custom Cancel
button) then just return null.

--
Dave Sexton

"Ant" <An*@discussions.microsoft.comwrote in message
news:D3**********************************@microsof t.com...

Hi,

I'm using a modal dialog box to input data. I have created properties on the
dialog form to capture the data so that it might be read from the main form
via the dialog form. This approach encapsulates the data & I can implement
the business logic in the dialog form.

This leaves me with the quiestion. There is no Class representing the data
I'm capturing, (say, it's a customer) apart from the dialog form class. The
form now represents the customer.

Are there problems with this approach? Should I create a Class solely for
the purpose of holding the customer data & pass that to the main form via
say, a delegate, or is it ok to hold data in the forms properties.

(e.g formCustomerInput.Name).

Thanks for any thoughts on this
Cheers
Ant

[Mark R. Dawson]

Hi Ant,
it is always best practise to keep the UI seperate from data wherever
possible, as Dave mentioned by creating a customer data type you can then
pass that data to other forms or other parts of your code, rather than ending
up with many unconnected variables. Also by separating your UI from your
business objects as much as possible will make it easier to refactor your UI
without causing you to have to refactor your underlying logic.

Another bonus if you are into testing your code is that testing your
underlying logic through a UI is hard, by separating your logic form the UI
you can easily unit test your business objects i.e. NUnit / Visual Studio etc
without a UI which is a lot easier.
Mark.
--
http://www.markdawson.org
"Ant" wrote:

Hi,

I'm using a modal dialog box to input data. I have created properties on the
dialog form to capture the data so that it might be read from the main form
via the dialog form. This approach encapsulates the data & I can implement
the business logic in the dialog form.

This leaves me with the quiestion. There is no Class representing the data
I'm capturing, (say, it's a customer) apart from the dialog form class. The
form now represents the customer.

Are there problems with this approach? Should I create a Class solely for
the purpose of holding the customer data & pass that to the main form via
say, a delegate, or is it ok to hold data in the forms properties.

(e.g formCustomerInput.Name).

Thanks for any thoughts on this
Cheers
Ant