Design Question - Buisiness Objects and Data Layer

[Matthias S.]

Hi,

I have to write an application which extensively uses an SQL Database.
For a simple example say I have the following tables with the
appropriate fields.

1. Company (ID, Name, AddresseInfoID)
2. AddresseInfo (ID, Street, City, Zip)

(Those two obviously have a relationship)

Now I'd go and create an object called Company and one for the
AddresseInfo. AddresseInfo would be a public member of Company.

Usually you'll have more than one company to manage so I create a
strongly typed collection called CompanyCollection.

Now on to the questions:
1. Should each individual object be responsible of loading and saving
it's data from and to the database or should the CompanyCollection take
care of it (which IMHO seems a lot less coding to me on first sight)?

2. Assumed the Collection takes care of the data-fetching, how should
then the data changes whithin the individual objects be handled? What
comes in mind is either a IsDirty property of each of the
BusinessObjects (Company and AddresseInfo) (which can be checked by the
collection) or an event (say DataChanged) to which the collection would
hook up.

The problem I see with this approach is the following. Say my MDI GUI
displays a list of all Companies in a TreeView on the lefthandside. On
DoubleClick the selected BusinessObject gets displayed in a new
"Document Window" which hosts a PropertyGrid control. Now my user opens
3 Companies and changes the data of all of them. How would I then handle
the situation when he only wants to save to of those documents?

Here is some additional information which I feel might be usefull:

a. The amount of BusinessObject loaded from the Database is never really
huge. Say a maximum of 2000 objects.

b. BusinessObjects might contain collections of other BusinessObjects,
e.g. the Company object will contain a EmployeeCollection.

c. The amount of different BusinessObjects will probably not exceed 20.

d. Performance issues are not a knock out criteria.

e. The solution that I'm after is simple to code and maintain. I don't
actually want to create a huge Framework with hundrets of classes which
provide for unlimited scalability and the forth. We are talking about an
application which is used by 10 people and new versions can be installed
at any time if required.

I hope someone can give me some advice on how to design this properly.

Thanks in advance,

Matthias

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Hi,

I have to write an application which extensively uses an SQL Database.
For a simple example say I have the following tables with the
appropriate fields.

1. Company (ID, Name, AddresseInfoID)
2. AddresseInfo (ID, Street, City, Zip)

(Those two obviously have a relationship)

Does a company has more than one address? if not you better make the above
one table

Now I'd go and create an object called Company and one for the
AddresseInfo. AddresseInfo would be a public member of Company.

I think that it depend of how you implement the other classes in your
design, if you need to treat the addesses in a particular way then yes, you
better do that, if not just make the AddresseInfo's members members of
Company

Usually you'll have more than one company to manage so I create a
strongly typed collection called CompanyCollection.
Yep

Now on to the questions:
1. Should each individual object be responsible of loading and saving
it's data from and to the database or should the CompanyCollection take
care of it (which IMHO seems a lot less coding to me on first sight)?

It depends , I think I have use both approach,
You may have a static property named something like "Companies " that
returns a list of company. then you have a LoadList method and here is where
you decide who load the actual company.
You could decide to do a select * from company and have the LoadList fill
all the fields of the instances.
or you can do a new Company( companyID ) and let that each instance load
itself.

The later can give you more flexibility to what/when to load it, you could
create a "lazy" loading method, where an instance load itself when needed.

2. Assumed the Collection takes care of the data-fetching, how should
then the data changes whithin the individual objects be handled? What
comes in mind is either a IsDirty property of each of the
BusinessObjects (Company and AddresseInfo) (which can be checked by the
collection) or an event (say DataChanged) to which the collection would
hook up.

That also depend of your app. You can implement such a method as you
describe, this will allow you to have a worker thread that iterate in the
collection and save as needed , NOTE that this will have BIG impact in the
concurrency protection that you use !!!!!!

Other method is having a Save() method in the Company class and that each
instance be responsible to save itself.

The problem I see with this approach is the following. Say my MDI GUI
displays a list of all Companies in a TreeView on the lefthandside. On
DoubleClick the selected BusinessObject gets displayed in a new
"Document Window" which hosts a PropertyGrid control. Now my user opens
3 Companies and changes the data of all of them. How would I then handle
the situation when he only wants to save to of those documents?

Use the second approach I described, a Company.Save() is issue as a
response to the user's save request.


Also take a look at a thread from last week named "Classes concepts"

Cheers,

 

[Nicholas Paldino [.NET/C# MVP]]

Matthais S.,

First, I would recommend using typed data sets for this sort of thing.
I would pass them through all layers of the application (front end,
business, data, etc, etc). They provide the heiarchical structure that you
want, easy binding capability, and all of the data classes will work with
them.

For the rest, see inline:

Now on to the questions:
1. Should each individual object be responsible of loading and saving it's
data from and to the database or should the CompanyCollection take care of
it (which IMHO seems a lot less coding to me on first sight)?

If you use the strongly typed data sets, then this shouldn't be an
issue. Generally though, I would say that this is based on the type of
relationship that you have between the objects. If the object is a owned by
the parent, then I would say that you should load it at the same time. If
it is just a relation, then I would say you could load it when needed. As
for saving, I would say having two routines is fine, as long as they are
both called within the same transaction scope (after all, a change in one
should imply a change in the other from a logical perspective, since the
relationship is one where the parent owns the child).

2. Assumed the Collection takes care of the data-fetching, how should then
the data changes whithin the individual objects be handled? What comes in
mind is either a IsDirty property of each of the BusinessObjects (Company
and AddresseInfo) (which can be checked by the collection) or an event
(say DataChanged) to which the collection would hook up.

If you use typed data sets, you can use a DataView on them which will
allow you to see only the rows that are changed.

The problem I see with this approach is the following. Say my MDI GUI
displays a list of all Companies in a TreeView on the lefthandside. On
DoubleClick the selected BusinessObject gets displayed in a new "Document
Window" which hosts a PropertyGrid control. Now my user opens 3 Companies
and changes the data of all of them. How would I then handle the situation
when he only wants to save to of those documents?

If each has it's own window, then they should require some sort of user
interaction to commit the changes. Until the user does that, you won't know
if they want to be saved or not. It doesn't really matter, until the user
saves the items.

Hope this helps.