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]

Re: Object design - Is 18 nested classes going to far?


"Andy B" <a_borka@sbcglo bal.netwrote in message
news:u0fwC62lIH A.944@TK2MSFTNG P05.phx.gbl...

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]

Re: Object design - Is 18 nested classes going to far?

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" <MR. Arnold@Arnold.c omwrote in message
news:OKJxwc4lIH A.5820@TK2MSFTN GP04.phx.gbl...

>
"Andy B" <a_borka@sbcglo bal.netwrote in message
news:u0fwC62lIH A.944@TK2MSFTNG P05.phx.gbl...
>

>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.
>
>

[Mr. Arnold]

Re: Object design - Is 18 nested classes going to far?


"Andy B" <a_borka@sbcglo bal.netwrote in message
news:%23giwPl4l IHA.5692@TK2MSF TNGP03.phx.gbl. ..

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.

>
>
"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
news:OKJxwc4lIH A.5820@TK2MSFTN GP04.phx.gbl...

>>
>"Andy B" <a_borka@sbcglo bal.netwrote in message
>news:u0fwC62lI HA.944@TK2MSFTN GP05.phx.gbl...
>>

>>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]

Re: Object design - Is 18 nested classes going to far?

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" <MR. Arnold@Arnold.c omwrote in message
news:exMSYQ5lIH A.2328@TK2MSFTN GP03.phx.gbl...

>
"Andy B" <a_borka@sbcglo bal.netwrote in message
news:%23giwPl4l IHA.5692@TK2MSF TNGP03.phx.gbl. ..

>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.
>

>>
>>
>"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
>news:OKJxwc4lI HA.5820@TK2MSFT NGP04.phx.gbl.. .

>>>
>>"Andy B" <a_borka@sbcglo bal.netwrote in message
>>news:u0fwC62l IHA.944@TK2MSFT NGP05.phx.gbl.. .
>>>
>>>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.
>>>
>>>

>>
>>

>

[Mr. Arnold]

Re: Object design - Is 18 nested classes going to far?


"Andy B" <a_borka@sbcglo bal.netwrote in message
news:OfxSRm5lIH A.1212@TK2MSFTN GP05.phx.gbl...

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.

"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
news:exMSYQ5lIH A.2328@TK2MSFTN GP03.phx.gbl...

>>
>"Andy B" <a_borka@sbcglo bal.netwrote in message
>news:%23giwPl4 lIHA.5692@TK2MS FTNGP03.phx.gbl ...

>>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.
>>

>>>
>>>
>>"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
>>news:OKJxwc4l IHA.5820@TK2MSF TNGP04.phx.gbl. ..
>>>>
>>>"Andy B" <a_borka@sbcglo bal.netwrote in message
>>>news:u0fwC62 lIHA.944@TK2MSF TNGP05.phx.gbl. ..
>>>>
>>>>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.
>>>>
>>>>
>>>
>>>

>>

>
>

[Leon Lambert]

Re: Object design - Is 18 nested classes going to far?

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 wrote:

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" <MR. Arnold@Arnold.c omwrote in message
news:exMSYQ5lIH A.2328@TK2MSFTN GP03.phx.gbl...

>"Andy B" <a_borka@sbcglo bal.netwrote in message
>news:%23giwPl4 lIHA.5692@TK2MS FTNGP03.phx.gbl ...

>>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.
>>

>>>
>>"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
>>news:OKJxwc4l IHA.5820@TK2MSF TNGP04.phx.gbl. ..
>>>"Andy B" <a_borka@sbcglo bal.netwrote in message
>>>news:u0fwC62 lIHA.944@TK2MSF TNGP05.phx.gbl. ..
>>>>
>>>>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]

Re: Object design - Is 18 nested classes going to far?

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?


"Leon Lambert" <lambertl@inil. comwrote in message
news:ubKacKKmIH A.1184@TK2MSFTN GP04.phx.gbl...

>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 wrote:

>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.Serializ e into an xml dataType column. Will probably take a bit of
>research for me to do though. Does this sound practicle?
>"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
>news:exMSYQ5lI HA.2328@TK2MSFT NGP03.phx.gbl.. .

>>"Andy B" <a_borka@sbcglo bal.netwrote in message
>>news:%23giwPl 4lIHA.5692@TK2M SFTNGP03.phx.gb l...
>>>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.
>>>
>>>>
>>>"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
>>>news:OKJxwc4 lIHA.5820@TK2MS FTNGP04.phx.gbl ...
>>>>"Andy B" <a_borka@sbcglo bal.netwrote in message
>>>>news:u0fwC6 2lIHA.944@TK2MS FTNGP05.phx.gbl ...
>>>>>
>>>>>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
>>>>NHibernat e 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.
>>>>>
>>>>>
>>>>

>>

[Michael D. Ober]

Re: Object design - Is 18 nested classes going to far?

"Andy B" <a_borka@sbcglo bal.netwrote in message
news:%23qUDc4Mm IHA.3940@TK2MSF TNGP05.phx.gbl. ..

>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?
>

The simple solution would be to scan in the signed contract and store the
scanned contract. Then you don't need to worry about changing the contract
by accident. You do still need a way to version contracts, but that would
be required even with paper storage (just slightly easier).

Mike.

[Ben Voigt [C++ MVP]]

Re: Object design - Is 18 nested classes going to far?

Peter Morris wrote:

>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.

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.