Design/Refactoring Question (DAL versus Objects)

[JM]

Hello,

I've got a design question, but I'll need to give some background first.

I've inherited a VB.NET WinForm application where the requirement was
"N-Tier". This was implemented based on the tables in the DB and the
name of UI elements. Saving is done via by using reflection and UI
containers. The value UI elements are copied to an object where the
property name matches the name of the DB element, and the property type
is string. Again using reflection, the object is copied over to
another object with the same name and a datatype that matches the DB,
after the form's "save" event has done the two copies, it calls a class
that is specific to the type of the 2nd object (I call it a class
because the class has a single shared method and nothing else), which
then calls one of three methods in a 2nd shared class (again no
instance info for the class). The 3 methods in this last class are
Create, Update and Delete and have the 2nd object as a parameter to be
used when creating sql parameters for Insert, Update and Delete
statements.

Now as to my question: I'm torn between turning the 2 shared classes
into methods on the 2nd object versus trying to create a more generic
data access approach (which isn't coming to me right now). So, what do
the experts here think and if they favor the data access, what would be
a rough description of what you think it should look like?

 

[Mr. Arnold]

Hello,

I've got a design question, but I'll need to give some background first.

I've inherited a VB.NET WinForm application where the requirement was
"N-Tier". This was implemented based on the tables in the DB and the
name of UI elements. Saving is done via by using reflection and UI
containers. The value UI elements are copied to an object where the
property name matches the name of the DB element, and the property type
is string. Again using reflection, the object is copied over to
another object with the same name and a datatype that matches the DB,
after the form's "save" event has done the two copies, it calls a class
that is specific to the type of the 2nd object (I call it a class
because the class has a single shared method and nothing else), which
then calls one of three methods in a 2nd shared class (again no
instance info for the class). The 3 methods in this last class are
Create, Update and Delete and have the 2nd object as a parameter to be
used when creating sql parameters for Insert, Update and Delete
statements.

Now as to my question: I'm torn between turning the 2 shared classes
into methods on the 2nd object versus trying to create a more generic
data access approach (which isn't coming to me right now). So, what do
the experts here think and if they favor the data access, what would be
a rough description of what you think it should look like?

An 'object' is like a little machine self-containing. The object should
know its state of the object is new-insert, old-update or marked for
deletion-delete, and methods within the object are acted upon by the
object to persist itself to the database. The object has a method or
methods that are called upon within itself to populate itself from the
database based in information in the object's properties.

It looks like you're talking about a 2-tier solution. The UI can be
directly in communications with the object's properties, populate the
object and tell the object to persists itself. Or you can use a Data
Transfer Object DTO that sits between the UI and the data object with a
mapper method within the data object that maps data between like
properties of the two object types. The UI would access the DTO to
get/set properties of the DTO using UI controls.

Like you have a form.save event, it should call object.save method, and
the object takes care of itself.

 

[Ralph]

Hello,

I've got a design question, but I'll need to give some background
first.

I've inherited a VB.NET WinForm application where the requirement was
"N-Tier".

That is the key. Just how closely do you need to be or are "required" to be
n-tiered?

[Obviously all design models and their terminology are far too complex to be
fully explained in this media. So what follows is a "10,000 foot view".
Accurate in the general, but less accurate in the specifics. <g>]

"N-Tier" implies a linear structural design and also implies the concept of
"layers" or published interfaces between the tiers.

The classic example is a three-tier client/server data access model where
Presentation is separated from the data store, and communication between the
two is managed by Middleware (which might be several 'tiers' itself). So we
have something like this ...

Application (eg, a dialog box with a Grid)
Business Rule / Business Object (eg, a data aware class)
Data Access Library (eg, ADO)
Data Access Provider
Database Engine / Data Store (SQL Server)

The linear structure is maintained in that the Application can only talk to
a clearly defined Business Object Interface. ie, it never communicates
directly with anything else farther down the line. The same with each of the
other elements.

The concept of 'layers' is best explained by substitution. In the ideal
N-Tier design we could substitute any one of the items above with something
different - and have no effect on any of the other layers as long as the
interface is preserved. ie, the 'application' could be a dialog box with a
Grid, a child window with a list view, an Office Table, etc. We might decide
to swap out data stores (Oracle, or an XML ...)

So whenever you 'break' the number of layers you are in essence 'breaking'
the isolation of each of the tiers. That is why it is important to
understand exactly what, the powers that be, had in mind by making that
requirement.

In your case it appears benign - unless that original break-up of the BR
into multiple BO is critical, because those objects are used in another
scenario.

[That help or only muddy the water more? <g>]

-ralph