OO question beginner

[.net lear]

if I have an object, say a recipe, which is added to a database, whose
responsibility is it to add to the db? The recipe or something else?

Let's say I want to delete a recipe? Does the recipe kill itself? Or does
the database or something else do the removal?

Where does the responsibility lie?

Thanks.

[Nick Malik [Microsoft]]

Usually, you will use the Layers pattern (see Buschmann) and you would
seperate the business object (recipe) from the CRUD code needed to insert or
delete it from the database (in the persistence layer)

The object itself is responsible for using the persistence layer, and for
knowing what methods to call to persist its data.

So, a recipe stores itself using the persistence layer, and a recipe deletes
itself using the persistence layer.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
".net lear" <asdfasdf> wrote in message
news:uu*************@TK2MSFTNGP12.phx.gbl...

if I have an object, say a recipe, which is added to a database, whose
responsibility is it to add to the db? The recipe or something else?

Let's say I want to delete a recipe? Does the recipe kill itself? Or does
the database or something else do the removal?

Where does the responsibility lie?

Thanks.

[.net lear]

ok thanks. I thought the recipe would be responsible but I don't know
anything about the persistence layer.
"Nick Malik [Microsoft]" <ni*******@hotmail.nospam.com> wrote in message
news:xe********************@comcast.com...

Usually, you will use the Layers pattern (see Buschmann) and you would
seperate the business object (recipe) from the CRUD code needed to insert or delete it from the database (in the persistence layer)

The object itself is responsible for using the persistence layer, and for
knowing what methods to call to persist its data.

So, a recipe stores itself using the persistence layer, and a recipe deletes itself using the persistence layer.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
".net lear" <asdfasdf> wrote in message
news:uu*************@TK2MSFTNGP12.phx.gbl...

if I have an object, say a recipe, which is added to a database, whose
responsibility is it to add to the db? The recipe or something else?

Let's say I want to delete a recipe? Does the recipe kill itself? Or does the database or something else do the removal?

Where does the responsibility lie?

Thanks.

[John Timney \(ASP.NET MVP\)]

The recipe only tells you how to cook the dish, it has no concept of where
the recipe is stored in your kitchen. As it happens its stored in the
cookbook (the persistence or data layer). storing the recipe has nothing to
do with cooking the dish, so you should refrain from including that logic in
your business layer (the recipe) - ideally the cookbook would do the
deletions and inserts with the recipe being an argument passed to it as the
persistence layer as inserts and deletions are something that occur to your
cookbook not your recipe.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

".net lear" <asdfasdf> wrote in message
news:uu*************@TK2MSFTNGP12.phx.gbl...

if I have an object, say a recipe, which is added to a database, whose
responsibility is it to add to the db? The recipe or something else?

Let's say I want to delete a recipe? Does the recipe kill itself? Or does
the database or something else do the removal?

Where does the responsibility lie?

Thanks.

[JV]

Well put!

"John Timney (ASP.NET MVP)" <ti*****@despammed.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

The recipe only tells you how to cook the dish, it has no concept of where
the recipe is stored in your kitchen. As it happens its stored in the
cookbook (the persistence or data layer). storing the recipe has nothing
to do with cooking the dish, so you should refrain from including that
logic in your business layer (the recipe) - ideally the cookbook would do
the deletions and inserts with the recipe being an argument passed to it
as the persistence layer as inserts and deletions are something that occur
to your cookbook not your recipe.

[.net lear]

Thanks a lot.

I'm just getting started with this concept, very used to procedural
programming.

Isn't the cookbook just a collection of recipes? In other words,
doesn't it inherit from recipe to some degree?

When you say "stored in the cookbook (persistence or data layer)", can
you elaborate? What does that mean?
John Timney (ASP.NET MVP) wrote:

The recipe only tells you how to cook the dish, it has no concept of where
the recipe is stored in your kitchen. As it happens its stored in the
cookbook (the persistence or data layer). storing the recipe has nothing to
do with cooking the dish, so you should refrain from including that logic in
your business layer (the recipe) - ideally the cookbook would do the
deletions and inserts with the recipe being an argument passed to it as the
persistence layer as inserts and deletions are something that occur to your
cookbook not your recipe.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

".net lear" <asdfasdf> wrote in message
news:uu*************@TK2MSFTNGP12.phx.gbl...

if I have an object, say a recipe, which is added to a database, whose
responsibility is it to add to the db? The recipe or something else?

Let's say I want to delete a recipe? Does the recipe kill itself? Or does
the database or something else do the removal?

Where does the responsibility lie?

Thanks.

[John Timney \(ASP.NET MVP\)]

How it inherits depends on your encapsulation, and whether there is any
interaction between the cookbook and the recipe. In an ideal OO scanrio the
recipe should be self contained, telling you only how to make the dish. The
cookbook knows nothing about making the dish, thus it needs to inherit none
of the properties of the recipe to function as a cookbook - it only needs to
contain recipe objects, like a namespace containing lots of different
classes. The classes in the namespace can be interelated by existing in the
namespace, but need not know anything about each other unless thats how to
need the objects to interact. Connected to this, the way you serve the
recipe (the presentation (layer)) has nothing to do with how it is stored in
the cookbook (persistence (layer)) or how it is cooked (business (layer))

Mutli tiered or layered implementations perform different and self contained
elements of your programming logic, like your presentation layer knowing
about plates and cress but nothing about cooking times. Theres a very nice
and straingtforward explanation of multi tiered applications here that might
be worth taking a look at.

http://www.dfpug.de/konf/konf_1999/g...ier/e_tier.htm

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

".net lear" <ms*********@gmail.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

Thanks a lot.

I'm just getting started with this concept, very used to procedural
programming.

Isn't the cookbook just a collection of recipes? In other words,
doesn't it inherit from recipe to some degree?

When you say "stored in the cookbook (persistence or data layer)", can
you elaborate? What does that mean?
John Timney (ASP.NET MVP) wrote:

The recipe only tells you how to cook the dish, it has no concept of
where
the recipe is stored in your kitchen. As it happens its stored in the
cookbook (the persistence or data layer). storing the recipe has nothing
to
do with cooking the dish, so you should refrain from including that logic
in
your business layer (the recipe) - ideally the cookbook would do the
deletions and inserts with the recipe being an argument passed to it as
the
persistence layer as inserts and deletions are something that occur to
your
cookbook not your recipe.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

".net lear" <asdfasdf> wrote in message
news:uu*************@TK2MSFTNGP12.phx.gbl...

> if I have an object, say a recipe, which is added to a database, whose
> responsibility is it to add to the db? The recipe or something else?
>
> Let's say I want to delete a recipe? Does the recipe kill itself? Or
> does
> the database or something else do the removal?
>
> Where does the responsibility lie?
>
> Thanks.
>
>
>

[.net lear]

thanks a lot.
"John Timney (ASP.NET MVP)" <ti*****@despammed.com> wrote in message
news:Ol****************@TK2MSFTNGP09.phx.gbl...

How it inherits depends on your encapsulation, and whether there is any
interaction between the cookbook and the recipe. In an ideal OO scanrio the recipe should be self contained, telling you only how to make the dish. The cookbook knows nothing about making the dish, thus it needs to inherit none of the properties of the recipe to function as a cookbook - it only needs to contain recipe objects, like a namespace containing lots of different
classes. The classes in the namespace can be interelated by existing in the namespace, but need not know anything about each other unless thats how to
need the objects to interact. Connected to this, the way you serve the
recipe (the presentation (layer)) has nothing to do with how it is stored in the cookbook (persistence (layer)) or how it is cooked (business (layer))

Mutli tiered or layered implementations perform different and self contained elements of your programming logic, like your presentation layer knowing
about plates and cress but nothing about cooking times. Theres a very nice and straingtforward explanation of multi tiered applications here that might be worth taking a look at.

http://www.dfpug.de/konf/konf_1999/g...ier/e_tier.htm

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

".net lear" <ms*********@gmail.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

Thanks a lot.

I'm just getting started with this concept, very used to procedural
programming.

Isn't the cookbook just a collection of recipes? In other words,
doesn't it inherit from recipe to some degree?

When you say "stored in the cookbook (persistence or data layer)", can
you elaborate? What does that mean?
John Timney (ASP.NET MVP) wrote:

The recipe only tells you how to cook the dish, it has no concept of
where
the recipe is stored in your kitchen. As it happens its stored in the
cookbook (the persistence or data layer). storing the recipe has nothing to
do with cooking the dish, so you should refrain from including that logic in
your business layer (the recipe) - ideally the cookbook would do the
deletions and inserts with the recipe being an argument passed to it as
the
persistence layer as inserts and deletions are something that occur to
your
cookbook not your recipe.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

".net lear" <asdfasdf> wrote in message
news:uu*************@TK2MSFTNGP12.phx.gbl...
> if I have an object, say a recipe, which is added to a database, whose > responsibility is it to add to the db? The recipe or something else?
>
> Let's say I want to delete a recipe? Does the recipe kill itself? Or
> does
> the database or something else do the removal?
>
> Where does the responsibility lie?
>
> Thanks.
>
>
>