OO class design question (logic placement)...

[Brad Pears]

Here is a simple OO design question...

I have a Contract class. The user can either save an existing contract or
they start off fresh with a blank contract, fill in the data and then save a
"new" contract.

I have a method in my contract class called "Save" which is called like
this...

dim oContract as new Contract
objContract.Save(me.txtContractNo)

when the user clicks the 'Save" icon on the contract form.

As you can see from the above code, the contract number is a paramter of the
"Save" method.

My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a new
one?? WOuld this be placed in the Contract class that is handling the save
operation or should it be left to the programmer to add logic to do this on
the form's save button?

I am thinking that it would be best to place this code in the Contract
class. Basically the logic is that if the contract number being passed to
the Save method is empty then we need to get the next available contract
number and save the contract using that #. If the contract number being
passed in has a value, then we will simply save the exisiting contract.

I think that it makes the most sense to place that logic within the class -
then the programmer does not need to do any checking - as it will always be
done by the class "Save" method...

Does this makes sense??

Thanks Brad

[Spam Catcher]

"Brad Pears" <br***@truenorthloghomes.comwrote in
news:u1**************@TK2MSFTNGP04.phx.gbl:

My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a
new one?? WOuld this be placed in the Contract class that is handling
the save operation or should it be left to the programmer to add logic
to do this on the form's save button?

I would place the data inside the contact object. The contact object should
be aware of it's present state (i.e. new vs. update).

Take a look at LLBLGen Pro - it's DAL framework does this sort of thing.

[Mr. Arnold]

>
I think that it makes the most sense to place that logic within the
class - then the programmer does not need to do any checking - as it will
always be done by the class "Save" method...

Does this makes sense??

The object should be able to set its state upon instantiate.

Upon the instantiation of the object, the object state is I am NEW, and I am
not DIRTY. I am not DIRTY, because no change has taken place within me.

If a change has taken place within me (the object), then I am marked DIRTY.

I the object will be OLD, if data from the database has populated me. I will
be DIRTY, because the database logic has populated me. I will be marked not
DIRTY.

I have another state called MARKED_FOR_DELETION too.

1) Upon the instantiation of me (the object), my state will be NEW. I am
NEW no data from the database has populated me, so when I am saved, my data
will be added/inserted into the database.

2) Upon instantiation I (the object), I am NEW and not DIRTY, but data has
populated me so I am going to be marked as OLD and not DIRTY. When I am
saved, I am going to update the database with my data.
Oh, my Save method has been invoked.

What is my state me (the object)?

1) I am DIRTY some change as taken place with in me. If I am not DIRTY, then
don't do anything with me and ignore me.

2) I am NEW and DIRTY, so add my data to the database.

3) I am OLD and DIRTY, so update my data in the database.

Hey, I am none of that. I am MARKED_FOR_DELETION.

1) If I am NEW and MARKED_FOR_DELETION, don't do anything with me (the
object) as I have no data that needs to be deleted from the database.

2) If I am OLD and MARKED_FOR_DELETION, I have data in the database so
delete my data.

Hey, me (the object) those could possibly be my states and how my Save
method might work.

[Daniel Bass]

Brad,

I'd suggest it's not really an OO question as much as general forms decision
making.

One approach is to vear from the other answers you have (although not to
contradict anything that's been said) and suggets that you split up the
concept of the Contract object and the Contract form.

The object understands how to load itself, save itself, and you could even
(for example) have a static method on the contract obect that checks whether
an instance of this object already exists.

The form simply gets data from the user and closes down once the form has
been "OK'd". From here, your code would query properties on the Contract
form object, passing them to a contract object. The final step is to call
save on the contract object, which decides whether it needs to create a new
object, update/overwrite to an existing object...

The File object works this way. There's the open dialog, save dialog, and
the File object.... When you open a file you first query what file is to be
opened using the file open dialog, and then use the file object's filename
property to open that file, read from it etc.
The second approach would be to simply use the data controls to build your
form, and use the view/edit/save funcationality that comes with the
gridview, databindernavigator and so on...
It all depends the context of the application...
ASP.Net: http://www.ondotnet.com/pub/a/dotnet...spdatactl.html
Windows: http://www.codeproject.com/csharp/Bi...ndingNavCS.asp
"Brad Pears" <br***@truenorthloghomes.comwrote in message
news:u1**************@TK2MSFTNGP04.phx.gbl...

Here is a simple OO design question...

I have a Contract class. The user can either save an existing contract or
they start off fresh with a blank contract, fill in the data and then save
a "new" contract.

I have a method in my contract class called "Save" which is called like
this...

dim oContract as new Contract
objContract.Save(me.txtContractNo)

when the user clicks the 'Save" icon on the contract form.

As you can see from the above code, the contract number is a paramter of
the "Save" method.

My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a new
one?? WOuld this be placed in the Contract class that is handling the save
operation or should it be left to the programmer to add logic to do this
on the form's save button?

I am thinking that it would be best to place this code in the Contract
class. Basically the logic is that if the contract number being passed to
the Save method is empty then we need to get the next available contract
number and save the contract using that #. If the contract number being
passed in has a value, then we will simply save the exisiting contract.

I think that it makes the most sense to place that logic within the
class - then the programmer does not need to do any checking - as it will
always be done by the class "Save" method...

Does this makes sense??

Thanks Brad

[Brad Pears]

Very well written. Thanks for that... Make some sense now...

Thanks, Brad

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:uD**************@TK2MSFTNGP02.phx.gbl...

>

>>
I think that it makes the most sense to place that logic within the
class - then the programmer does not need to do any checking - as it will
always be done by the class "Save" method...

Does this makes sense??

The object should be able to set its state upon instantiate.

Upon the instantiation of the object, the object state is I am NEW, and I
am not DIRTY. I am not DIRTY, because no change has taken place within me.

If a change has taken place within me (the object), then I am marked
DIRTY.

I the object will be OLD, if data from the database has populated me. I
will be DIRTY, because the database logic has populated me. I will be
marked not DIRTY.

I have another state called MARKED_FOR_DELETION too.

1) Upon the instantiation of me (the object), my state will be NEW. I am
NEW no data from the database has populated me, so when I am saved, my
data will be added/inserted into the database.

2) Upon instantiation I (the object), I am NEW and not DIRTY, but data
has populated me so I am going to be marked as OLD and not DIRTY. When I
am saved, I am going to update the database with my data.
Oh, my Save method has been invoked.

What is my state me (the object)?

1) I am DIRTY some change as taken place with in me. If I am not DIRTY,
then don't do anything with me and ignore me.

2) I am NEW and DIRTY, so add my data to the database.

3) I am OLD and DIRTY, so update my data in the database.

Hey, I am none of that. I am MARKED_FOR_DELETION.

1) If I am NEW and MARKED_FOR_DELETION, don't do anything with me (the
object) as I have no data that needs to be deleted from the database.

2) If I am OLD and MARKED_FOR_DELETION, I have data in the database so
delete my data.

Hey, me (the object) those could possibly be my states and how my Save
method might work.

[Brad Pears]

Hmmm sounds intertesting enough...

I do have another question though...

You mentioned about having a static method on the contract object that
checks whether an instance of the object already exisits or not...
How would you code such a method?? How could you call this method if in
fact the object does not exist? ( I am assuming this is where the static
part comes in - I just don;t understand what you mean) Since I am very new
to OO design, I do not quite understand that one...

I do like the idea of having a property on the object once instantiated that
is the object's "state" which would indicate once the save button is hit
what should be done with the object ... i.e. save new, save existing,
delete me, do nothing etc.. as meniotned by the fellow who wrote the 2nd
response...

Thanks, Brad

"Daniel Bass" <da***********@blueCAPSbottle.comFIRSTwrote in message
news:ej**************@TK2MSFTNGP05.phx.gbl...

Brad,

I'd suggest it's not really an OO question as much as general forms
decision making.

One approach is to vear from the other answers you have (although not to
contradict anything that's been said) and suggets that you split up the
concept of the Contract object and the Contract form.

The object understands how to load itself, save itself, and you could even
(for example) have a static method on the contract obect that checks
whether an instance of this object already exists.

The form simply gets data from the user and closes down once the form has
been "OK'd". From here, your code would query properties on the Contract
form object, passing them to a contract object. The final step is to call
save on the contract object, which decides whether it needs to create a
new object, update/overwrite to an existing object...

The File object works this way. There's the open dialog, save dialog, and
the File object.... When you open a file you first query what file is to
be opened using the file open dialog, and then use the file object's
filename property to open that file, read from it etc.
The second approach would be to simply use the data controls to build your
form, and use the view/edit/save funcationality that comes with the
gridview, databindernavigator and so on...
It all depends the context of the application...
ASP.Net: http://www.ondotnet.com/pub/a/dotnet...spdatactl.html
Windows: http://www.codeproject.com/csharp/Bi...ndingNavCS.asp
"Brad Pears" <br***@truenorthloghomes.comwrote in message
news:u1**************@TK2MSFTNGP04.phx.gbl...

>Here is a simple OO design question...

I have a Contract class. The user can either save an existing contract or
they start off fresh with a blank contract, fill in the data and then
save a "new" contract.

I have a method in my contract class called "Save" which is called like
this...

dim oContract as new Contract
objContract.Save(me.txtContractNo)

when the user clicks the 'Save" icon on the contract form.

As you can see from the above code, the contract number is a paramter of
the "Save" method.

My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a new
one?? WOuld this be placed in the Contract class that is handling the
save operation or should it be left to the programmer to add logic to do
this on the form's save button?

I am thinking that it would be best to place this code in the Contract
class. Basically the logic is that if the contract number being passed to
the Save method is empty then we need to get the next available contract
number and save the contract using that #. If the contract number being
passed in has a value, then we will simply save the exisiting contract.

I think that it makes the most sense to place that logic within the
class - then the programmer does not need to do any checking - as it will
always be done by the class "Save" method...

Does this makes sense??

Thanks Brad

[Brad Pears]

Where can I take a look at what you mentioned there - the LLBLGen Pro?

Thanks, Brad
"Spam Catcher" <sp**********@rogers.comwrote in message
news:Xn**********************************@127.0.0. 1...

"Brad Pears" <br***@truenorthloghomes.comwrote in
news:u1**************@TK2MSFTNGP04.phx.gbl:

>My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a
new one?? WOuld this be placed in the Contract class that is handling
the save operation or should it be left to the programmer to add logic
to do this on the form's save button?

I would place the data inside the contact object. The contact object
should
be aware of it's present state (i.e. new vs. update).

Take a look at LLBLGen Pro - it's DAL framework does this sort of thing.

[Rory Becker]

You mentioned about having a static method on the contract object that

checks whether an instance of the object already exisits or not...
How would you code such a method?? How could you call this method if
in
fact the object does not exist? ( I am assuming this is where the
static
part comes in - I just don;t understand what you mean)

It sounds like you are talking about the singleton pattern

In this case Static means Shared (Static is the c# keyword)

Thus:
-----------------------------------------------------------
Private Shared Singleton as SomeClass
Public Shared Function GetSingleton() as SomeClass
If Singleton is nothing then
Singleton = New SomeClass
Endif
return Singleton
End Function
-----------------------------------------------------------
--
Rory

[Rory Becker]

Where can I take a look at what you mentioned there - the LLBLGen Pro?

>

www.llblgen.com

--
Rory

[Brad Pears]

That was very well written. I had never thought of having a property 'State'
that is set for the object but I think it makes sense...

Basically what I have happeneing now is that the "Save" method on the
business class "contract" object calls an "update" method on the contract
"data class" object. ( I split the object so that I have a business object
"contract" and a data object "contract_data"). This update method in turn
runs a stored procedure to do the job. The stored procedure itself
determines whether or not to "update" the data or "insert" the data. There
is a completely separate method to "delete" a contract which in turn runs a
stored procedure to specifically do just that...

So implementing a state property really doesn't buy me anything in this
instance BUT I do like the idea of having a state on every object and I
think it makes sense. Is this a common thing to have?? I have not seen a lot
of this in reading OO material or viewing OO design techniques/coding
techniques...

Thanks, Brad

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:uD**************@TK2MSFTNGP02.phx.gbl...

>

>>
I think that it makes the most sense to place that logic within the
class - then the programmer does not need to do any checking - as it will
always be done by the class "Save" method...

Does this makes sense??

The object should be able to set its state upon instantiate.

Upon the instantiation of the object, the object state is I am NEW, and I
am not DIRTY. I am not DIRTY, because no change has taken place within me.

If a change has taken place within me (the object), then I am marked
DIRTY.

I the object will be OLD, if data from the database has populated me. I
will be DIRTY, because the database logic has populated me. I will be
marked not DIRTY.

I have another state called MARKED_FOR_DELETION too.

1) Upon the instantiation of me (the object), my state will be NEW. I am
NEW no data from the database has populated me, so when I am saved, my
data will be added/inserted into the database.

2) Upon instantiation I (the object), I am NEW and not DIRTY, but data
has populated me so I am going to be marked as OLD and not DIRTY. When I
am saved, I am going to update the database with my data.
Oh, my Save method has been invoked.

What is my state me (the object)?

1) I am DIRTY some change as taken place with in me. If I am not DIRTY,
then don't do anything with me and ignore me.

2) I am NEW and DIRTY, so add my data to the database.

3) I am OLD and DIRTY, so update my data in the database.

Hey, I am none of that. I am MARKED_FOR_DELETION.

1) If I am NEW and MARKED_FOR_DELETION, don't do anything with me (the
object) as I have no data that needs to be deleted from the database.

2) If I am OLD and MARKED_FOR_DELETION, I have data in the database so
delete my data.

Hey, me (the object) those could possibly be my states and how my Save
method might work.

[Spam Catcher]

"Brad Pears" <br***@truenorthloghomes.comwrote in
news:#i**************@TK2MSFTNGP04.phx.gbl:

So implementing a state property really doesn't buy me anything in
this instance BUT I do like the idea of having a state on every object
and I think it makes sense. Is this a common thing to have?? I have
not seen a lot of this in reading OO material or viewing OO design
techniques/coding techniques...

Yes, having a state is common.

In fact, it might be a good idea to update the state property whenever
the field changes :-)

For example:

Public Property MyProperty as String
Get
Return MyPropertyValue
End Get
Set(Byval value as string)
If value <MyPropertyValue Then
Me.State = Enum.Dirty
End If

value = MyProperty
End Set

[Brad Pears]

Thanks, I will take a look see!

Brad

"Rory Becker" <Ro********@newsgroup.nospamwrote in message
news:b0**************************@msnews.microsoft .com...

>Where can I take a look at what you mentioned there - the LLBLGen Pro?

www.llblgen.com

--
Rory

[Brad Pears]

Ok, maybe I will get you to elaborate a bit on that code... just becasue I
don't want to second guess what you are doing being so new to this and
all... and I
like what you are proposing with updating the state whenever a property
changes...

In the line of code...
"me.state = Enum.dirty", what class is enum from ? Can you elaborate there a
bit?

Also, as far as the object states go - These are really the states I need to
worry about correct?
1) I am new so insert me
2) I am old and dirtry so update me
3) I am old and not dirty so ignore me
4) marked for deletion so delete me

Thanks, Brad
"Spam Catcher" <sp**********@rogers.comwrote in message
news:Xn**********************************@127.0.0. 1...

"Brad Pears" <br***@truenorthloghomes.comwrote in
news:#i**************@TK2MSFTNGP04.phx.gbl:

>So implementing a state property really doesn't buy me anything in
this instance BUT I do like the idea of having a state on every object
and I think it makes sense. Is this a common thing to have?? I have
not seen a lot of this in reading OO material or viewing OO design
techniques/coding techniques...

Yes, having a state is common.

In fact, it might be a good idea to update the state property whenever
the field changes :-)

For example:

Public Property MyProperty as String
Get
Return MyPropertyValue
End Get
Set(Byval value as string)
If value <MyPropertyValue Then
Me.State = Enum.Dirty
End If

value = MyProperty
End Set

[Spam Catcher]

"Brad Pears" <br***@truenorthloghomes.comwrote in
news:#5*************@TK2MSFTNGP06.phx.gbl:

In the line of code...
"me.state = Enum.dirty", what class is enum from ? Can you elaborate
there a bit?

You'll need to create your own list of enums for whatever states you want
to track (i.e. New, Update, etc).

Also, as far as the object states go - These are really the states I
need to worry about correct?
1) I am new so insert me
2) I am old and dirtry so update me
3) I am old and not dirty so ignore me
4) marked for deletion so delete me

Yes, that pretty much covers it.

[sloan]

You can read my take on it here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry

I believe in Controller or Manager classes to seperate the objects from the
code that saves/creates them.

"Brad Pears" <br***@truenorthloghomes.comwrote in message
news:u1**************@TK2MSFTNGP04.phx.gbl...

Here is a simple OO design question...

I have a Contract class. The user can either save an existing contract or
they start off fresh with a blank contract, fill in the data and then save

a

"new" contract.

I have a method in my contract class called "Save" which is called like
this...

dim oContract as new Contract
objContract.Save(me.txtContractNo)

when the user clicks the 'Save" icon on the contract form.

As you can see from the above code, the contract number is a paramter of

the

"Save" method.

My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a new
one?? WOuld this be placed in the Contract class that is handling the save
operation or should it be left to the programmer to add logic to do this

on

the form's save button?

I am thinking that it would be best to place this code in the Contract
class. Basically the logic is that if the contract number being passed to
the Save method is empty then we need to get the next available contract
number and save the contract using that #. If the contract number being
passed in has a value, then we will simply save the exisiting contract.

I think that it makes the most sense to place that logic within the

class -

then the programmer does not need to do any checking - as it will always

be

done by the class "Save" method...

Does this makes sense??

Thanks Brad

[Brad Pears]

Ok, next retarded question... How/where do I create these "enums" you are
referring to??

Thanks, Brad
"Spam Catcher" <sp**********@rogers.comwrote in message
news:Xn*********************************@127.0.0.1 ...

"Brad Pears" <br***@truenorthloghomes.comwrote in
news:#5*************@TK2MSFTNGP06.phx.gbl:

>In the line of code...
"me.state = Enum.dirty", what class is enum from ? Can you elaborate
there a bit?

You'll need to create your own list of enums for whatever states you want
to track (i.e. New, Update, etc).

>Also, as far as the object states go - These are really the states I
need to worry about correct?
1) I am new so insert me
2) I am old and dirtry so update me
3) I am old and not dirty so ignore me
4) marked for deletion so delete me

Yes, that pretty much covers it.

[Rory Becker]

Ok, next retarded question... How/where do I create these "enums"

you are referring to??

An example of an enumeration:
-------------------------------------------------------------
Public Enum CleanOrDirty
Clean
Dirty
End enum

Public Sub X()
Dim Y as CleanOrDirty ' Defaults to Clean
Y = CleanOrDirty.Dirty
y = CleanOrDirty.Clean

if y = CleanOrDirty.Clean then
messagebox.Show("Y is Clean")
Endif

End Sub
-------------------------------------------------------------
An enum is not restricted to only 2 values either and can have a different
scope if you wish.
--
Rory

[Brad Pears]

Perect!!! Thanks for that. I have never used these before at all.

Brad

"Rory Becker" <Ro********@newsgroup.nospamwrote in message
news:b0**************************@msnews.microsoft .com...

>Ok, next retarded question... How/where do I create these "enums"
you are referring to??

An example of an enumeration:
-------------------------------------------------------------
Public Enum CleanOrDirty
Clean
Dirty
End enum

Public Sub X()
Dim Y as CleanOrDirty ' Defaults to Clean
Y = CleanOrDirty.Dirty
y = CleanOrDirty.Clean

if y = CleanOrDirty.Clean then messagebox.Show("Y is Clean")
Endif
End Sub -------------------------------------------------------------
An enum is not restricted to only 2 values either and can have a different
scope if you wish.
--
Rory

[Cor Ligthert [MVP]]

Brad,

If you really want to use classic Unix methods instead of Net methods
(AdoNet and all its benefits), than at least make 3 layers, a DataLayer than
handles your DataBase, a Business layer than handles your class and all the
rules about, and UI layer than communicates with the User. DataLayer <>
Business Layer <UI layer. Never let the UI communicate with the DataLayer,
although sometimes you have the idea that it is better.

Happy coding, I assume you do this for hobby, because for business, this
takes in my idea a lot more time than the general dotNet methods.

Cor

"Brad Pears" <br***@truenorthloghomes.comschreef in bericht
news:u1**************@TK2MSFTNGP04.phx.gbl...

Here is a simple OO design question...

I have a Contract class. The user can either save an existing contract or
they start off fresh with a blank contract, fill in the data and then save
a "new" contract.

I have a method in my contract class called "Save" which is called like
this...

dim oContract as new Contract
objContract.Save(me.txtContractNo)

when the user clicks the 'Save" icon on the contract form.

As you can see from the above code, the contract number is a paramter of
the "Save" method.

My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a new
one?? WOuld this be placed in the Contract class that is handling the save
operation or should it be left to the programmer to add logic to do this
on the form's save button?

I am thinking that it would be best to place this code in the Contract
class. Basically the logic is that if the contract number being passed to
the Save method is empty then we need to get the next available contract
number and save the contract using that #. If the contract number being
passed in has a value, then we will simply save the exisiting contract.

I think that it makes the most sense to place that logic within the
class - then the programmer does not need to do any checking - as it will
always be done by the class "Save" method...

Does this makes sense??

Thanks Brad

[Brad Pears]

Thanks for you help...

No I am doing this for business. I have programmed in many different
languages over the years but this is my FIRST experience in OO design and
also my FIRST experience with VB.NET and SQL server. Previous to this I was
using Access 2000 and an Access DB and using some OO techniques but NEVER
did I ever design a classes etc.. etc...

Prior to that it was DbaseIV, Clipper, COBOL and PL1. So you can see I come
from way back!! This is really new to me and a lot of the way we used to do
things and think have to be thrown out or used sparingly when it comes to
the .NET framework and OO principals!! Very hard for an old dog like myself
to pick it all up and turn out a well designed and written application!!

Brad

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:eq**************@TK2MSFTNGP06.phx.gbl...

Brad,

If you really want to use classic Unix methods instead of Net methods
(AdoNet and all its benefits), than at least make 3 layers, a DataLayer
than handles your DataBase, a Business layer than handles your class and
all the rules about, and UI layer than communicates with the User.
DataLayer <Business Layer <UI layer. Never let the UI communicate with
the DataLayer, although sometimes you have the idea that it is better.

Happy coding, I assume you do this for hobby, because for business, this
takes in my idea a lot more time than the general dotNet methods.

Cor

"Brad Pears" <br***@truenorthloghomes.comschreef in bericht
news:u1**************@TK2MSFTNGP04.phx.gbl...

>Here is a simple OO design question...

I have a Contract class. The user can either save an existing contract or
they start off fresh with a blank contract, fill in the data and then
save a "new" contract.

I have a method in my contract class called "Save" which is called like
this...

dim oContract as new Contract
objContract.Save(me.txtContractNo)

when the user clicks the 'Save" icon on the contract form.

As you can see from the above code, the contract number is a paramter of
the "Save" method.

My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a new
one?? WOuld this be placed in the Contract class that is handling the
save operation or should it be left to the programmer to add logic to do
this on the form's save button?

I am thinking that it would be best to place this code in the Contract
class. Basically the logic is that if the contract number being passed to
the Save method is empty then we need to get the next available contract
number and save the contract using that #. If the contract number being
passed in has a value, then we will simply save the exisiting contract.

I think that it makes the most sense to place that logic within the
class - then the programmer does not need to do any checking - as it will
always be done by the class "Save" method...

Does this makes sense??

Thanks Brad

[Mr. Arnold]

"Brad Pears" <br***@truenorthloghomes.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

That was very well written. I had never thought of having a property
'State' that is set for the object but I think it makes sense...

Basically what I have happeneing now is that the "Save" method on the
business class "contract" object calls an "update" method on the contract
"data class" object. ( I split the object so that I have a business object
"contract" and a data object "contract_data"). This update method in turn
runs a stored procedure to do the job. The stored procedure itself
determines whether or not to "update" the data or "insert" the data. There
is a completely separate method to "delete" a contract which in turn runs
a stored procedure to specifically do just that...

I like to separate all three functions of add, update or delete, whether
that be with a stored procedure or with dynamic SQL statements in code.

>
So implementing a state property really doesn't buy me anything in this
instance BUT I do like the idea of having a state on every object and I
think it makes sense. Is this a common thing to have?? I have not seen a
lot of this in reading OO material or viewing OO design techniques/coding
techniques...

The state property, which can also be implemented at the business level as
well allows one to know the state of the object when dealing with the object
at the UI, Business or Data Access level.

I always at any level of the logical tiers of UI, Business and DALC I want
to know the object's state. Object what is your state so that I can take the
correct processing path.

Take for instance the case where you have a Business Object Collection a
collection that's holding multiple business objects, and during the
BOC.Save, it starts walking the collection invoking each object's
object.save, then I may need to know the state of the object. Maybe, I need
to populate an object with a parent key from a parent object or other things
like that, before I save the object.

What's the state of the Business Object Collection is the BOC DIRTY, because
a object within the BOC has been marked DIRTY so it's DIRTY too? Why should
I invoke the BOC.Save and start walking the collection when no object is
DIRTY within the BOC, because the user pushed the Save button?

There is another state of an object called IsValid. The object is asked to
validate itself. If the object is not valid, the why should I invoke the
Object.save? If all objects are not valid within the BOC if its IsValid is
false, then why should I invoke the BCO.Save.

Where I leaned all of this in using VB 6 for those solutions back in the
day, VB.NET and C#.NET, which I have been using these OOps concepts, since
year 2000, from Web, Windows desktop, Console and NT Service applications
for .NET is CSLA.

http://www.lhotka.net/Article.aspx?i...b-e0059cc82ee7

If you like, you can get the book, read the book, understand what's in the
book, download the framework put it together, download the project put it
together to use the framework and then you'll understand OO programming
techniques.

Keep in mind now, it's not about trying to implement a framework, which most
companies do use some kind of framework, in house written as an example.
It's about understanding the concepts, who are the players and how are the
players being used.

And then saying to yourself, I can use these concepts, I can make my own
objects, I don't need the CSLA framework, and I can run with this myself.

[Cor Ligthert [MVP]]

Brad,

Why are you so fixed on OO and not on OOP, I would look first to the later,
in Net are so much classes with build in OO that it will save you a lot of
time to focus your eyes on the later. Building all the classes from scratch
is in my eyes ridicilous.

As I wrote before, the complete OOP dataset and other ADONET features are
build on the relational model from SQL based database servers (they all have
the same model), however there is nothing better than those at the moment
than those servers..

Do you want to go the classic OO way, than you have in my idea first to take
a look at Linq.

Cor

"Brad Pears" <br***@truenorthloghomes.comschreef in bericht
news:O1**************@TK2MSFTNGP02.phx.gbl...

Thanks for you help...

No I am doing this for business. I have programmed in many different
languages over the years but this is my FIRST experience in OO design and
also my FIRST experience with VB.NET and SQL server. Previous to this I
was using Access 2000 and an Access DB and using some OO techniques but
NEVER did I ever design a classes etc.. etc...

Prior to that it was DbaseIV, Clipper, COBOL and PL1. So you can see I
come from way back!! This is really new to me and a lot of the way we
used to do things and think have to be thrown out or used sparingly when
it comes to the .NET framework and OO principals!! Very hard for an old
dog like myself to pick it all up and turn out a well designed and written
application!!

Brad

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:eq**************@TK2MSFTNGP06.phx.gbl...

>Brad,

If you really want to use classic Unix methods instead of Net methods
(AdoNet and all its benefits), than at least make 3 layers, a DataLayer
than handles your DataBase, a Business layer than handles your class and
all the rules about, and UI layer than communicates with the User.
DataLayer <Business Layer <UI layer. Never let the UI communicate
with the DataLayer, although sometimes you have the idea that it is
better.

Happy coding, I assume you do this for hobby, because for business, this
takes in my idea a lot more time than the general dotNet methods.

Cor

"Brad Pears" <br***@truenorthloghomes.comschreef in bericht
news:u1**************@TK2MSFTNGP04.phx.gbl...

>>Here is a simple OO design question...

I have a Contract class. The user can either save an existing contract
or they start off fresh with a blank contract, fill in the data and then
save a "new" contract.

I have a method in my contract class called "Save" which is called like
this...

dim oContract as new Contract
objContract.Save(me.txtContractNo)

when the user clicks the 'Save" icon on the contract form.

As you can see from the above code, the contract number is a paramter of
the "Save" method.

My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a new
one?? WOuld this be placed in the Contract class that is handling the
save operation or should it be left to the programmer to add logic to do
this on the form's save button?

I am thinking that it would be best to place this code in the Contract
class. Basically the logic is that if the contract number being passed
to the Save method is empty then we need to get the next available
contract number and save the contract using that #. If the contract
number being passed in has a value, then we will simply save the
exisiting contract.

I think that it makes the most sense to place that logic within the
class - then the programmer does not need to do any checking - as it
will always be done by the class "Save" method...

Does this makes sense??

Thanks Brad

[Spam Catcher]

"Cor Ligthert [MVP]" <no************@planet.nlwrote in
news:uz**************@TK2MSFTNGP04.phx.gbl:

Do you want to go the classic OO way, than you have in my idea first
to take a look at Linq.

Is Linq even available? It's still in Alpha or Beta right?

[Brad Pears]

Ok, I think I am missing something really big. OO = Object Oriented,
OOP=???? Isn't it Object Oriented Principals or Programming?? What is the
difference between OO and OOP?? I gues I don;t know what OOP really stands
for if OO and OOP are different...

Thanks, Brad

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:uz**************@TK2MSFTNGP04.phx.gbl...

Brad,

Why are you so fixed on OO and not on OOP, I would look first to the
later, in Net are so much classes with build in OO that it will save you
a lot of time to focus your eyes on the later. Building all the classes
from scratch is in my eyes ridicilous.

As I wrote before, the complete OOP dataset and other ADONET features are
build on the relational model from SQL based database servers (they all
have the same model), however there is nothing better than those at the
moment than those servers..

Do you want to go the classic OO way, than you have in my idea first to
take a look at Linq.

Cor

"Brad Pears" <br***@truenorthloghomes.comschreef in bericht
news:O1**************@TK2MSFTNGP02.phx.gbl...

>Thanks for you help...

No I am doing this for business. I have programmed in many different
languages over the years but this is my FIRST experience in OO design and
also my FIRST experience with VB.NET and SQL server. Previous to this I
was using Access 2000 and an Access DB and using some OO techniques but
NEVER did I ever design a classes etc.. etc...

Prior to that it was DbaseIV, Clipper, COBOL and PL1. So you can see I
come from way back!! This is really new to me and a lot of the way we
used to do things and think have to be thrown out or used sparingly when
it comes to the .NET framework and OO principals!! Very hard for an old
dog like myself to pick it all up and turn out a well designed and
written application!!

Brad

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:eq**************@TK2MSFTNGP06.phx.gbl...

>>Brad,

If you really want to use classic Unix methods instead of Net methods
(AdoNet and all its benefits), than at least make 3 layers, a DataLayer
than handles your DataBase, a Business layer than handles your class and
all the rules about, and UI layer than communicates with the User.
DataLayer <Business Layer <UI layer. Never let the UI communicate
with the DataLayer, although sometimes you have the idea that it is
better.

Happy coding, I assume you do this for hobby, because for business, this
takes in my idea a lot more time than the general dotNet methods.

Cor

"Brad Pears" <br***@truenorthloghomes.comschreef in bericht
news:u1**************@TK2MSFTNGP04.phx.gbl...
Here is a simple OO design question...

I have a Contract class. The user can either save an existing contract
or they start off fresh with a blank contract, fill in the data and
then save a "new" contract.

I have a method in my contract class called "Save" which is called like
this...

dim oContract as new Contract
objContract.Save(me.txtContractNo)

when the user clicks the 'Save" icon on the contract form.

As you can see from the above code, the contract number is a paramter
of the "Save" method.

My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a new
one?? WOuld this be placed in the Contract class that is handling the
save operation or should it be left to the programmer to add logic to
do this on the form's save button?

I am thinking that it would be best to place this code in the Contract
class. Basically the logic is that if the contract number being passed
to the Save method is empty then we need to get the next available
contract number and save the contract using that #. If the contract
number being passed in has a value, then we will simply save the
exisiting contract.

I think that it makes the most sense to place that logic within the
class - then the programmer does not need to do any checking - as it
will always be done by the class "Save" method...

Does this makes sense??

Thanks Brad

[Armin Zingler]

"Brad Pears" <br***@truenorthloghomes.comschrieb

Ok, I think I am missing something really big. OO = Object Oriented,
OOP=???? Isn't it Object Oriented Principals or Programming?? What
is the difference between OO and OOP?? I gues I don;t know what OOP
really stands for if OO and OOP are different...

An academic question. I did OOP in VB6. Some say it wasn't OOP because VB6
didn't support inheritance. I say, it was OOP because my "orientation was
programming with objects".
Armin

[Rory Becker]

"Brad Pears" <br***@truenorthloghomes.comschrieb

>

>Ok, I think I am missing something really big. OO = Object Oriented,
OOP=???? Isn't it Object Oriented Principals or Programming?? What is
the difference between OO and OOP?? I gues I don;t know what OOP
really stands for if OO and OOP are different...

I'm afraid I cannot answer this original question. I have always heard these
2 terms as interchangable and have never heard anything which suggests otherwise.

I would be interested to hear what others have to say on the subject.

An academic question.

I did OOP in VB6. Some say it wasn't OOP because
VB6 didn't support inheritance.
I say, it was OOP because my
"orientation was programming with objects".

I also worked with Vb6 and 5 and 3 before that.

It is *generally* accepted that VB6 is not Object-Oriented but Object-based.

Within programming things are labelled by the community at large and in this
case Armin you may choose to call VB6 Object-oriented but the term has more
than a literal meaning it is a specific labell that categorises languages
that support "Inheritence", "Encapsulation" and "Polymorphism".

Vb6 supports only "Interface Inheritance" and not "Implementation Inheritance"
and therefore most professional programmers will discount it from the object-oriented
label

This is likely to start a big religious debate so I suggest that the OP perform
some searches of his own to prove this to himself.

All of the quoted terms should be understood and supported by a language
that tries to make this claim

--
Rory

[Cor Ligthert [MVP]]

Brad,

OOP is not only working with OO (data) classes. The whole concept is based
on Objects which are initiated from a class. Every time you create a new
object and use that, until it goes out of scope or any other reason it is
not necessary anymore, than you destroy it. However, the last is not
necessary in managed code anymore because that is exactly what is managed
for you.

Just a very short way of trying to tell what is my (and not only my) idea
about OOP.

In other words, your program is build with objects which are instanced from
classes and not with modules as in the classic VB way. (In Net modules have
as well the name shared or static classes. In fact they are consequently in
memory as a VB module normally was too. (When they were not separated in
extra DLL's or whatever).

Cor

"Brad Pears" <br***@truenorthloghomes.comschreef in bericht
news:uA**************@TK2MSFTNGP06.phx.gbl...

Ok, I think I am missing something really big. OO = Object Oriented,
OOP=???? Isn't it Object Oriented Principals or Programming?? What is the
difference between OO and OOP?? I gues I don;t know what OOP really
stands for if OO and OOP are different...

Thanks, Brad

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:uz**************@TK2MSFTNGP04.phx.gbl...

>Brad,

Why are you so fixed on OO and not on OOP, I would look first to the
later, in Net are so much classes with build in OO that it will save you
a lot of time to focus your eyes on the later. Building all the classes
from scratch is in my eyes ridicilous.

As I wrote before, the complete OOP dataset and other ADONET features are
build on the relational model from SQL based database servers (they all
have the same model), however there is nothing better than those at the
moment than those servers..

Do you want to go the classic OO way, than you have in my idea first to
take a look at Linq.

Cor

"Brad Pears" <br***@truenorthloghomes.comschreef in bericht
news:O1**************@TK2MSFTNGP02.phx.gbl...

>>Thanks for you help...

No I am doing this for business. I have programmed in many different
languages over the years but this is my FIRST experience in OO design
and also my FIRST experience with VB.NET and SQL server. Previous to
this I was using Access 2000 and an Access DB and using some OO
techniques but NEVER did I ever design a classes etc.. etc...

Prior to that it was DbaseIV, Clipper, COBOL and PL1. So you can see I
come from way back!! This is really new to me and a lot of the way we
used to do things and think have to be thrown out or used sparingly when
it comes to the .NET framework and OO principals!! Very hard for an old
dog like myself to pick it all up and turn out a well designed and
written application!!

Brad

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:eq**************@TK2MSFTNGP06.phx.gbl...
Brad,

If you really want to use classic Unix methods instead of Net methods
(AdoNet and all its benefits), than at least make 3 layers, a DataLayer
than handles your DataBase, a Business layer than handles your class
and all the rules about, and UI layer than communicates with the User.
DataLayer <Business Layer <UI layer. Never let the UI communicate
with the DataLayer, although sometimes you have the idea that it is
better.

Happy coding, I assume you do this for hobby, because for business,
this takes in my idea a lot more time than the general dotNet methods.

Cor

"Brad Pears" <br***@truenorthloghomes.comschreef in bericht
news:u1**************@TK2MSFTNGP04.phx.gbl...
Here is a simple OO design question...
>
I have a Contract class. The user can either save an existing contract
or they start off fresh with a blank contract, fill in the data and
then save a "new" contract.
>
I have a method in my contract class called "Save" which is called
like this...
>
dim oContract as new Contract
objContract.Save(me.txtContractNo)
>
when the user clicks the 'Save" icon on the contract form.
>
As you can see from the above code, the contract number is a paramter
of the "Save" method.
>
My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a
new one?? WOuld this be placed in the Contract class that is handling
the save operation or should it be left to the programmer to add logic
to do this on the form's save button?
>
I am thinking that it would be best to place this code in the Contract
class. Basically the logic is that if the contract number being passed
to the Save method is empty then we need to get the next available
contract number and save the contract using that #. If the contract
number being passed in has a value, then we will simply save the
exisiting contract.
>
I think that it makes the most sense to place that logic within the
class - then the programmer does not need to do any checking - as it
will always be done by the class "Save" method...
>
Does this makes sense??
>
Thanks Brad
>

[Armin Zingler]

"Rory Becker" <Ro********@newsgroup.nospamschrieb

It is *generally* accepted that VB6 is not Object-Oriented but
Object-based.

That's why I called it an academic question.
Armin

[Michael D. Ober]

Actually, I believe MS even referred to VB 6 as "Object Based" and not
"Object Oriented" for this very reason that it didn't support inheritance
and polymorphism.

Mike.

"Rory Becker" <Ro********@newsgroup.nospamwrote in message
news:b0**************************@msnews.microsoft .com...

>"Brad Pears" <br***@truenorthloghomes.comschrieb

>>Ok, I think I am missing something really big. OO = Object Oriented,
OOP=???? Isn't it Object Oriented Principals or Programming?? What is
the difference between OO and OOP?? I gues I don;t know what OOP
really stands for if OO and OOP are different...

I'm afraid I cannot answer this original question. I have always heard
these 2 terms as interchangable and have never heard anything which
suggests otherwise.

I would be interested to hear what others have to say on the subject.

>An academic question.

>I did OOP in VB6. Some say it wasn't OOP because
VB6 didn't support inheritance. I say, it was OOP because my
"orientation was programming with objects".

I also worked with Vb6 and 5 and 3 before that.
It is *generally* accepted that VB6 is not Object-Oriented but
Object-based.
Within programming things are labelled by the community at large and in
this case Armin you may choose to call VB6 Object-oriented but the term
has more than a literal meaning it is a specific labell that categorises
languages that support "Inheritence", "Encapsulation" and "Polymorphism".

Vb6 supports only "Interface Inheritance" and not "Implementation
Inheritance" and therefore most professional programmers will discount it
from the object-oriented label

This is likely to start a big religious debate so I suggest that the OP
perform some searches of his own to prove this to himself.

All of the quoted terms should be understood and supported by a language
that tries to make this claim

--
Rory

[Brad Pears]

Thanks everyone...

Yes, well you pretty much backed me up on what I thought it was... Basically
I had the feeling that is pretty much about the inheritance, polymorphism,
encapsulation etc...

Yes, I never have ever heard that VB6 was an "object oriented" language -
although possible to do some OO stuff there - just not enough to call it a
full fledged OO language... My sister in law was a Java developer for IBM
(was pretty high up too) and she pretty much poo-pooed any language that
called itself OO - even .NET products. (I think the only other one she had
used that she liked was VisualAge Smalltalk) But Java people seem to be
very dedicated to that product and don't really see (or care) what other
products can actually do... (I've known a few of them)

Thanks for helping clarify - I thought I was missing something!

Brad

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:eh****************@TK2MSFTNGP04.phx.gbl...

Brad,

OOP is not only working with OO (data) classes. The whole concept is based
on Objects which are initiated from a class. Every time you create a new
object and use that, until it goes out of scope or any other reason it is
not necessary anymore, than you destroy it. However, the last is not
necessary in managed code anymore because that is exactly what is managed
for you.

Just a very short way of trying to tell what is my (and not only my) idea
about OOP.

In other words, your program is build with objects which are instanced
from classes and not with modules as in the classic VB way. (In Net
modules have as well the name shared or static classes. In fact they are
consequently in memory as a VB module normally was too. (When they were
not separated in extra DLL's or whatever).

Cor

"Brad Pears" <br***@truenorthloghomes.comschreef in bericht
news:uA**************@TK2MSFTNGP06.phx.gbl...

>Ok, I think I am missing something really big. OO = Object Oriented,
OOP=???? Isn't it Object Oriented Principals or Programming?? What is the
difference between OO and OOP?? I gues I don;t know what OOP really
stands for if OO and OOP are different...

Thanks, Brad

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:uz**************@TK2MSFTNGP04.phx.gbl...

>>Brad,

Why are you so fixed on OO and not on OOP, I would look first to the
later, in Net are so much classes with build in OO that it will save
you a lot of time to focus your eyes on the later. Building all the
classes from scratch is in my eyes ridicilous.

As I wrote before, the complete OOP dataset and other ADONET features
are build on the relational model from SQL based database servers (they
all have the same model), however there is nothing better than those at
the moment than those servers..

Do you want to go the classic OO way, than you have in my idea first to
take a look at Linq.

Cor

"Brad Pears" <br***@truenorthloghomes.comschreef in bericht
news:O1**************@TK2MSFTNGP02.phx.gbl...
Thanks for you help...

No I am doing this for business. I have programmed in many different
languages over the years but this is my FIRST experience in OO design
and also my FIRST experience with VB.NET and SQL server. Previous to
this I was using Access 2000 and an Access DB and using some OO
techniques but NEVER did I ever design a classes etc.. etc...

Prior to that it was DbaseIV, Clipper, COBOL and PL1. So you can see I
come from way back!! This is really new to me and a lot of the way we
used to do things and think have to be thrown out or used sparingly
when it comes to the .NET framework and OO principals!! Very hard for
an old dog like myself to pick it all up and turn out a well designed
and written application!!

Brad

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:eq**************@TK2MSFTNGP06.phx.gbl...
Brad,
>
If you really want to use classic Unix methods instead of Net methods
(AdoNet and all its benefits), than at least make 3 layers, a
DataLayer than handles your DataBase, a Business layer than handles
your class and all the rules about, and UI layer than communicates
with the User. DataLayer <Business Layer <UI layer. Never let the
UI communicate with the DataLayer, although sometimes you have the
idea that it is better.
>
Happy coding, I assume you do this for hobby, because for business,
this takes in my idea a lot more time than the general dotNet methods.
>
Cor
>
"Brad Pears" <br***@truenorthloghomes.comschreef in bericht
news:u1**************@TK2MSFTNGP04.phx.gbl.. .
>Here is a simple OO design question...
>>
>I have a Contract class. The user can either save an existing
>contract or they start off fresh with a blank contract, fill in the
>data and then save a "new" contract.
>>
>I have a method in my contract class called "Save" which is called
>like this...
>>
>dim oContract as new Contract
>objContract.Save(me.txtContractNo)
>>
>when the user clicks the 'Save" icon on the contract form.
>>
>As you can see from the above code, the contract number is a paramter
>of the "Save" method.
>>
>My question is this... Where should the code be placed that actually
>determines whether we are saving an existing contract or creating a
>new one?? WOuld this be placed in the Contract class that is handling
>the save operation or should it be left to the programmer to add
>logic to do this on the form's save button?
>>
>I am thinking that it would be best to place this code in the
>Contract class. Basically the logic is that if the contract number
>being passed to the Save method is empty then we need to get the next
>available contract number and save the contract using that #. If the
>contract number being passed in has a value, then we will simply save
>the exisiting contract.
>>
>I think that it makes the most sense to place that logic within the
>class - then the programmer does not need to do any checking - as it
>will always be done by the class "Save" method...
>>
>Does this makes sense??
>>
>Thanks Brad
>>
>
>