Object design - Is 18 nested classes going to far?

[Andy B]

I need to decide on how to store online signed contracts for customers and
clients. I have considered a database in sql server 2005, but it seems to be
too complicated. Besides, if the contract contents or layout for new
contracts changes, I would have to change the whole database setup. Not to
mention that there would be a lot of repeated fields which could be a waste
of space. My next choice would be to keep the original unsigned blank (not
filled out) contract. in an xml file so it can be changed without bothering
all of the other contract copies. When some fills out and signs the
contract, it creates an xml file with the copy of the contract contents, the
filled out form and the fact that they had signed it. My only question is:
When I created the xsd file to define how the xml file output should look
like and ran it through xsd.exe, it created 18 nested objects. It also made
it to where there could be up to 60 objects created just for 1 filled
out/signed copy of this contract. Is there any possible way to do something
like this any better? If you need any examples of how this could be a
problem for me, I can give a few example situations below.

1. Definitions. Each word and it's definition for the contract dictionary
has to be an object. The contract has 12 dictionary entries, so that means
12 dictionary entries floating around loose. After this, they have to be
added to the dictionary. So, there are 24 dictionary entries created (2
copies of each entry).
2. Sections. Each divison of the contract is a "section". There are 21
different sections that need to be created as stand alone objects and then
added to the main Contract object (another 42 objects laying around).
3. Addresses. There are mulbiple addresses, but xsd.exe made it to where I
would need to create 6 address objects and then add them to the contract
object.

Anyways, is there any way to cut down on all of these loose objects sitting
around? Is there a different way besides xml/sql server that is secure that
I could look into for storing the contracts?

 

[Mr. Arnold]

Anyways, is there any way to cut down on all of these loose objects
sitting around? Is there a different way besides xml/sql server that is
secure that I could look into for storing the contracts?

You have a parent object and child objects that need to be saved. That's the
direction you should use is a database, like SQL Server. This could easily
be accomplished by making a database, creating the tables needed, and using
something like dotnet 3rd party integrated NHibernate tool to make the DAL
objects and plumbing for you based on the tables for you from the database.
What you need is tool that's going to make it easy for you.

 

[Andy B]

So, that's good, but what happens if the contract changes? I wouldn't want
the new changes to affect an already signed/fulfilled contract. The changes
made to it would only be able to change contracts that havent been created
yet. Is there a way to do that?

 

[Mr. Arnold]

So, that's good, but what happens if the contract changes? I wouldn't want
the new changes to affect an already signed/fulfilled contract. The
changes made to it would only be able to change contracts that havent been
created yet. Is there a way to do that?

Well if something changes something like a field taken away from a record or
added to a record, then you're going to have to regenerate the objects and
change code to accommodate the changes and recompile the solution. You may
also need to write a program to manipulate the data in the database to
reflect coding changes to the database. That's life in Information
Technology for a programmer, called maintinance.

 

[Andy B]

That's fine, but the contract changes have to be dynamically generated.
There will be a program module that will let an admin change the contract on
the fly and then have it take affect instantly the next time a blank
contract is generated. I have possibly a few ways to cut down on the clutter
of lots of objects setting around uselessly, but from what I can see, I will
never get away from the clutter of code to a point. I also thought about
creating sql databases and inserting the xml output of Xml.Serialize into an
xml dataType column. Will probably take a bit of research for me to do
though. Does this sound practicle?

 

[Mr. Arnold]

That's fine, but the contract changes have to be dynamically generated.
There will be a program module that will let an admin change the contract
on the fly and then have it take affect instantly the next time a blank
contract is generated. I have possibly a few ways to cut down on the
clutter of lots of objects setting around uselessly, but from what I can
see, I will never get away from the clutter of code to a point. I also
thought about creating sql databases and inserting the xml output of
Xml.Serialize into an xml dataType column. Will probably take a bit of
research for me to do though. Does this sound practicle?

I can't tell you, because I have not worked with XML in this manner. I have
only worked with XML to a point of making objects and saving objects to a
database and retrieving them. I guess you're going to have to find the
proper solution.

I know I worked on some insurance policy applications that needed to be
compliant by state with the appropriate data dynamic data from the policy
holder on the form that wasn't XML long ago. But, it was text based data
shown on the form and received into the database, so it can be done.

 

[Peter Morris]

1. Definitions. Each word and it's definition for the contract dictionary

has to be an object. The contract has 12 dictionary entries, so that means
12 dictionary entries floating around loose. After this, they have to be
added to the dictionary. So, there are 24 dictionary entries created (2
copies of each entry).

Your business objects really have 1 object for each word? That's overkill
in my opinion, why would you do that? I can't see why you would want to
separatly declare the definitions either, those are done inline within the
section text.

2. Sections. Each divison of the contract is a "section". There are 21
different sections that need to be created as stand alone objects and then
added to the main Contract object (another 42 objects laying around).
3. Addresses. There are mulbiple addresses, but xsd.exe made it to where I
would need to create 6 address objects and then add them to the contract
object.

Key
[ClassName] = Name of a class
(RoleName) = Name of a role / association to a class
0..* = Multiplicity


[Contract] (Contract) 1----1..* (Versions) [ContractVersion]

[ContractVersion] (Version) 1----1..* (Sections) [ContractSection]


Contract c = new Contract();
c.Title = "Blah blah blah";

ContractSection cs = new ContractSection();
cs.Body = "Blah blah (hereinafter referred to as Bling Bling) shall hereby
........";
cs.SectionNumber = "1.1";
c.CurrentVersion.Sections.Add(cs);

cs = new ContractSection();
cs.Body = "Blah blah (hereinafter referred to as Bling Bling) shall hereby
........";
cs.SectionNumber = "1.2";
c.CurrentVersion.Sections.Add(cs);

c.CurrentVersion.MakeLive();

c.CreateNewVersion();
c.CurrentVersion.SectionByNumber("1.1").Body += "Amen";
c.CurrentVersion.MakeLive();

etc


Pete

 

[Leon Lambert]

I am certainly no lawyer but i would think you would need to keep all
versions of the contracts. Once a contract was signed i don't think
anyone can come along and edit it without getting it signed again. This
would mean to me that once a contract was signed it was frozen for that
customer and any changes made would only apply to new customers. This
would then imply you need some sort of version control on the contracts.
I know i certainly would not be happy if someone changed a contract I
had already reviewed with my lawyer and then signed.

Something to think about
Leon Lambert

 

[Andy B]

I never planned on changing it after its been signed. The original question
was: What storage method would best be used if you wanted to change a blank
contract without affecting the ones already locked and frozen?

 

[Ben Voigt [C++ MVP]]

Your business objects really have 1 object for each word? That's
overkill in my opinion, why would you do that? I can't see why you
would want to separatly declare the definitions either, those are
done inline within the section text.

For one thing, it would allow you to compare each definition against a table
of usual definitions and flag any that are unusual for detailed
consideration.