471,325 Members | 1,701 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,325 software developers and data experts.

Object design - Is 18 nested classes going to far?

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?

Apr 5 '08 #1
9 1293

"Andy B" <a_*****@sbcglobal.netwrote in message
news:u0*************@TK2MSFTNGP05.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.
Apr 6 '08 #2
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. Ar****@Arnold.comwrote in message
news:OK**************@TK2MSFTNGP04.phx.gbl...
>
"Andy B" <a_*****@sbcglobal.netwrote in message
news:u0*************@TK2MSFTNGP05.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.


Apr 6 '08 #3

"Andy B" <a_*****@sbcglobal.netwrote in message
news:%2****************@TK2MSFTNGP03.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. Ar****@Arnold.comwrote in message
news:OK**************@TK2MSFTNGP04.phx.gbl...
>>
"Andy B" <a_*****@sbcglobal.netwrote in message
news:u0*************@TK2MSFTNGP05.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.


Apr 6 '08 #4
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. Ar****@Arnold.comwrote in message
news:ex**************@TK2MSFTNGP03.phx.gbl...
>
"Andy B" <a_*****@sbcglobal.netwrote in message
news:%2****************@TK2MSFTNGP03.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. Ar****@Arnold.comwrote in message
news:OK**************@TK2MSFTNGP04.phx.gbl...
>>>
"Andy B" <a_*****@sbcglobal.netwrote in message
news:u0*************@TK2MSFTNGP05.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.



Apr 6 '08 #5

"Andy B" <a_*****@sbcglobal.netwrote in message
news:Of**************@TK2MSFTNGP05.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. Ar****@Arnold.comwrote in message
news:ex**************@TK2MSFTNGP03.phx.gbl...
>>
"Andy B" <a_*****@sbcglobal.netwrote in message
news:%2****************@TK2MSFTNGP03.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. Ar****@Arnold.comwrote in message
news:OK**************@TK2MSFTNGP04.phx.gbl...

"Andy B" <a_*****@sbcglobal.netwrote in message
news:u0*************@TK2MSFTNGP05.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.


Apr 6 '08 #6
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. Ar****@Arnold.comwrote in message
news:ex**************@TK2MSFTNGP03.phx.gbl...
>"Andy B" <a_*****@sbcglobal.netwrote in message
news:%2****************@TK2MSFTNGP03.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. Ar****@Arnold.comwrote in message
news:OK**************@TK2MSFTNGP04.phx.gbl...
"Andy B" <a_*****@sbcglobal.netwrote in message
news:u0*************@TK2MSFTNGP05.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.

Apr 7 '08 #7
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" <la******@inil.comwrote in message
news:ub**************@TK2MSFTNGP04.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.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. Ar****@Arnold.comwrote in message
news:ex**************@TK2MSFTNGP03.phx.gbl...
>>"Andy B" <a_*****@sbcglobal.netwrote in message
news:%2****************@TK2MSFTNGP03.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. Ar****@Arnold.comwrote in message
news:OK**************@TK2MSFTNGP04.phx.gbl...
"Andy B" <a_*****@sbcglobal.netwrote in message
news:u0*************@TK2MSFTNGP05.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.
>
>
Apr 7 '08 #8
"Andy B" <a_*****@sbcglobal.netwrote in message
news:%2****************@TK2MSFTNGP05.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.
Apr 8 '08 #9
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.
Apr 10 '08 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

13 posts views Thread by Bryan Parkoff | last post: by
6 posts views Thread by B0nj | last post: by
4 posts views Thread by scottrm | last post: by
18 posts views Thread by D Witherspoon | last post: by
4 posts views Thread by news.microsoft.com | last post: by
2 posts views Thread by miked | last post: by
17 posts views Thread by Jef Driesen | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.