switching the usual order of things

[AllenL]

Ever since I've been using objects with VB I've instantiated the
business object from the form; the business object then
creates/destroys data access layer objects as needed. The business
object also maintains state for the form variables. The form unload /
closing event destroys the business object.

For a small set of specialized forms in .NET, I want to try switching
the usual order of things. The business class will optionally
instantiate the form (modal), passing a reference of itself in the
form constructor as in:

from any code in the application...

Private cMy As MyClass
cMy = New MyClass(True)
or
Private cMy As MyClass = New MyClass(True)

If IsNothing(cMy) = False Then cMy = Nothing

------------------------------------------

If the parameter in the class constructor is True, the form will show
as in:

MyClass

Private cF As MyForm

Friend Sub New(ByVal bDisplayForm as Boolean)

If bDisplayForm Then DisplayForm

End Sub

Private Sub DisplayForm
cF = New MyForm(Me) ' pass reference to class
cF.ShowDialog()
End Sub

...various properties that tie to variables on the form

------------------------------------------

MyForm

Private cMy2 As MyClass

Friend Sub New(By Ref c As MyClass)
cMy2 = c
End Sub

' cMy2 and cMy should now point to the same object
' business class properties/methods are now visible at form
' level


QUESTION:

Both business and form objects will be in the same runtime location.
The class will destroy the form. Does anyone see any potential
problems with this methodology?

Thanks.

****** AllenL ********************************************************

In a nation ruled by swine, all pigs are upward-mobile...
Hunter S. Thompson (b. 1939), U.S. journalist.

 

[Peter Huang [MSFT]]

Hi Allen,

The code will not cause serious problem. But it will make the code lack of
maintainability and readability.

Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

--------------------

 

[AllenL]

Hi Allen,

The code will not cause serious problem. But it will make the code lack of
maintainability and readability.

Regards,
Peter Huang
Microsoft Online Partner Support

<snip>

Thanks for the reply.

One of these objects will be used as the sole source of crypto
functionality in the application (though possibly excluding encrypted
streams). As far as readability is concerned, the more obscure the
better.

The object will serve a dual purpose: handling encryption/decryption
for sensitive database columns (credit card numbers, social security
numbers, etc.) and, when the optional form is called, validating and
authenticating passwords and managing password changes.

This business layer will still consume data layer objects as required.
Its just that rather than the password form owning the business layer
object, the business layer object will own the form.

I've previously written a .NET crypto component consumed by a password
form -- where crypto is involved I would rather like to have all the
source in one component.

Regards,

Allen

****** AllenL ********************************************************

In a nation ruled by swine, all pigs are upward-mobile...
Hunter S. Thompson (b. 1939), U.S. journalist.