469,322 Members | 1,982 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,322 developers. It's quick & easy.

OOD theory question

bo'jour, bo'jour,
So I have question to present to the forum about OOD. This is a Csharp
forum, but C# is the lang of choice and the question is an exercise based on
some comments by the chief designer of C#. Those of you who are junkies for
design principle might be interested in contributing to this thread.

I was recently reading some interviews with the chief engineer for C#
(formerly Mr. Delphi), and he made an interesting comment about how you use
objects as representations, and the path you choose in this respect has a
big impact on the way you write code. For instance, does your user object
represent a copy of data about a user or does it represent the user
him/herself?

This made me think about how we represent users in web applications.

Scenario: web application lets users change information about themselves
(address, billing info, etc), information about each is in persistent
storage somewhere. Web form has fields for address information and a 'save'
button that does the obvious.

The question is this:
Do you:
1) instantiate a user object, set appropriate fields and call a user.save()
method
2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately
2) instantiate a user object, usrMyUser, set appropriate fields, instantiate
a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)

Each possibility represents a different way of looking at the user object
(as an avatar for the real user vs. a representation of user information).
If the user object is a representation of user information, in theory it
wouldn't have any methods, simply properties and be nothing more than a
custom data type. If the user object is an avatar, it will come at the price
of efficiency and maintainability (you'll be making more calls to the data
store, and the entity itself will be interacting with data directly rather
than having a workflow object pass the entity through various stages of
processing).

I think this is a legitimate question about design technique, but if you
think I'm missing something obvious, please let me know. I'd like to see a
conversation develop about the pros and cons to each approach or new
approaches I haven't mentioned here. I've got definite critical opinions
about each of the options mentioned above, but I'll wait to point them out
in a follow-up if this post is successful in starting a thread.

Thanks for your input, and I hope to hear more from you all.
Nov 15 '05 #1
15 1630
In article <#N**************@TK2MSFTNGP09.phx.gbl>,
th*********@hotmail.com says...
bo'jour, bo'jour,
So I have question to present to the forum about OOD. This is a Csharp
forum, but C# is the lang of choice and the question is an exercise based on
some comments by the chief designer of C#. Those of you who are junkies for
design principle might be interested in contributing to this thread.

I was recently reading some interviews with the chief engineer for C#
(formerly Mr. Delphi), and he made an interesting comment about how you use
objects as representations, and the path you choose in this respect has a
big impact on the way you write code. For instance, does your user object
represent a copy of data about a user or does it represent the user
him/herself?

This made me think about how we represent users in web applications.

Scenario: web application lets users change information about themselves
(address, billing info, etc), information about each is in persistent
storage somewhere. Web form has fields for address information and a 'save'
button that does the obvious.

The question is this:
Do you:
1) instantiate a user object, set appropriate fields and call a user.save()
method
2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately
2) instantiate a user object, usrMyUser, set appropriate fields, instantiate
a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)

Each possibility represents a different way of looking at the user object
(as an avatar for the real user vs. a representation of user information).
If the user object is a representation of user information, in theory it
wouldn't have any methods, simply properties and be nothing more than a
custom data type. If the user object is an avatar, it will come at the price
of efficiency and maintainability (you'll be making more calls to the data
store, and the entity itself will be interacting with data directly rather
than having a workflow object pass the entity through various stages of
processing).

I think this is a legitimate question about design technique, but if you
think I'm missing something obvious, please let me know. I'd like to see a
conversation develop about the pros and cons to each approach or new
approaches I haven't mentioned here. I've got definite critical opinions
about each of the options mentioned above, but I'll wait to point them out
in a follow-up if this post is successful in starting a thread.

Thanks for your input, and I hope to hear more from you all.


I'm my opinion,
1) instantiate a user object, set appropriate fields and call a
user.save() method

This is a simple representation and maps the web form more.

2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately

This does put all of the Users's responsibility in the it's class, but
for effiency reasons it would have to use a buffer (See below)

3) instantiate a user object, usrMyUser, set appropriate fields,
instantiate a workflow object for a UserManager (for instance) and
call UserManager.SaveUser(usrMyUser)

A command object, more efficient but not much different that 1). And
puts the responsibility away from the User.

If you have a IPersistable interface and let any class that needs to
save itself implement that. Then that allows you to have a buffer of
some sort, so when a change occurs in User (or any IPersistable) you can
add this to a collection of IPersitable objects and go through them
calling Save at a more convenient time. This of course involves another
class, but in the Data Layer. Perhaps called Persist, with a collection
of IPersistables.

Sorry for rabbiting on, this was just another way you could design this
in C#. I think in real world you have to balance effiency and also keep
a good OO design.
--
Thanks
Mark mm
Nov 15 '05 #2
Have an .AutoSave property , if thats set, update the persistant storage for
every propset. if its false, require a .save() call.

Thats how Stream.Flush() works, you have .AutoFlush = true | false; and you
can call .Flush() if you desure. Its also called on .Close(),

"Mark mm" <ma********@hotmail.com> wrote in message
news:MP************************@News.CIS.DFN.DE...
In article <#N**************@TK2MSFTNGP09.phx.gbl>,
th*********@hotmail.com says...
bo'jour, bo'jour,
So I have question to present to the forum about OOD. This is a Csharp
forum, but C# is the lang of choice and the question is an exercise based on some comments by the chief designer of C#. Those of you who are junkies for design principle might be interested in contributing to this thread.

I was recently reading some interviews with the chief engineer for C#
(formerly Mr. Delphi), and he made an interesting comment about how you use objects as representations, and the path you choose in this respect has a big impact on the way you write code. For instance, does your user object represent a copy of data about a user or does it represent the user
him/herself?

This made me think about how we represent users in web applications.

Scenario: web application lets users change information about themselves
(address, billing info, etc), information about each is in persistent
storage somewhere. Web form has fields for address information and a 'save' button that does the obvious.

The question is this:
Do you:
1) instantiate a user object, set appropriate fields and call a user.save() method
2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately
2) instantiate a user object, usrMyUser, set appropriate fields, instantiate a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)

Each possibility represents a different way of looking at the user object (as an avatar for the real user vs. a representation of user information). If the user object is a representation of user information, in theory it
wouldn't have any methods, simply properties and be nothing more than a
custom data type. If the user object is an avatar, it will come at the price of efficiency and maintainability (you'll be making more calls to the data store, and the entity itself will be interacting with data directly rather than having a workflow object pass the entity through various stages of
processing).

I think this is a legitimate question about design technique, but if you
think I'm missing something obvious, please let me know. I'd like to see a conversation develop about the pros and cons to each approach or new
approaches I haven't mentioned here. I've got definite critical opinions
about each of the options mentioned above, but I'll wait to point them out in a follow-up if this post is successful in starting a thread.

Thanks for your input, and I hope to hear more from you all.


I'm my opinion,
1) instantiate a user object, set appropriate fields and call a
user.save() method

This is a simple representation and maps the web form more.

2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately

This does put all of the Users's responsibility in the it's class, but
for effiency reasons it would have to use a buffer (See below)

3) instantiate a user object, usrMyUser, set appropriate fields,
instantiate a workflow object for a UserManager (for instance) and
call UserManager.SaveUser(usrMyUser)

A command object, more efficient but not much different that 1). And
puts the responsibility away from the User.

If you have a IPersistable interface and let any class that needs to
save itself implement that. Then that allows you to have a buffer of
some sort, so when a change occurs in User (or any IPersistable) you can
add this to a collection of IPersitable objects and go through them
calling Save at a more convenient time. This of course involves another
class, but in the Data Layer. Perhaps called Persist, with a collection
of IPersistables.

Sorry for rabbiting on, this was just another way you could design this
in C#. I think in real world you have to balance effiency and also keep
a good OO design.
--
Thanks
Mark mm

Nov 15 '05 #3
<di********@discussion.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Have an .AutoSave property , if thats set, update the persistant storage for every propset. if its false, require a .save() call.


Inefficient as hell.

You hav to change 5 properties, and 5 updates go to the database.

Impressive.
--
Regards

Thomas Tomiczek
THONA Software & Consulting Ltd.
(Microsoft MVP C#/.NET)
(CTO PowerNodes Ltd.)
---

Still waiting for ObjectSpaces? Tr the EntityBroker today - more versatile,
more powerfull.
And something in use NOW. for the projects you have to deliver - NOW.

Nov 15 '05 #4
Its optional, if you dont want it, dont use it.

You can set AutoSave = false and it wont update on every propset, just on
the .Save();

How hard was that to understand? Did you actually read what I wrote?

"Thomas Tomiczek [MVP]" <t.********@thona-consulting.com> wrote in message
news:ut*************@TK2MSFTNGP12.phx.gbl...
<di********@discussion.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Have an .AutoSave property , if thats set, update the persistant storage for
every propset. if its false, require a .save() call.


Inefficient as hell.

You hav to change 5 properties, and 5 updates go to the database.

Impressive.
--
Regards

Thomas Tomiczek
THONA Software & Consulting Ltd.
(Microsoft MVP C#/.NET)
(CTO PowerNodes Ltd.)
---

Still waiting for ObjectSpaces? Tr the EntityBroker today - more

versatile, more powerfull.
And something in use NOW. for the projects you have to deliver - NOW.

Nov 15 '05 #5
Hello,

I prefer the 3rd option, it gives you a clear separation of the jobs, and
this way bloated classes are avoided.
A very good book treating all this aspects and much more is:
Patterns of Enterprise Application Architecture (Addison Wesley)
By Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee,
Randy Stafford

Best regards,
Relu.
"designconcepts" <th*********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
bo'jour, bo'jour,
So I have question to present to the forum about OOD. This is a Csharp
forum, but C# is the lang of choice and the question is an exercise based on some comments by the chief designer of C#. Those of you who are junkies for design principle might be interested in contributing to this thread.

I was recently reading some interviews with the chief engineer for C#
(formerly Mr. Delphi), and he made an interesting comment about how you use objects as representations, and the path you choose in this respect has a
big impact on the way you write code. For instance, does your user object
represent a copy of data about a user or does it represent the user
him/herself?

This made me think about how we represent users in web applications.

Scenario: web application lets users change information about themselves
(address, billing info, etc), information about each is in persistent
storage somewhere. Web form has fields for address information and a 'save' button that does the obvious.

The question is this:
Do you:
1) instantiate a user object, set appropriate fields and call a user.save() method
2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately
2) instantiate a user object, usrMyUser, set appropriate fields, instantiate a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)

Each possibility represents a different way of looking at the user object
(as an avatar for the real user vs. a representation of user information).
If the user object is a representation of user information, in theory it
wouldn't have any methods, simply properties and be nothing more than a
custom data type. If the user object is an avatar, it will come at the price of efficiency and maintainability (you'll be making more calls to the data
store, and the entity itself will be interacting with data directly rather
than having a workflow object pass the entity through various stages of
processing).

I think this is a legitimate question about design technique, but if you
think I'm missing something obvious, please let me know. I'd like to see a
conversation develop about the pros and cons to each approach or new
approaches I haven't mentioned here. I've got definite critical opinions
about each of the options mentioned above, but I'll wait to point them out
in a follow-up if this post is successful in starting a thread.

Thanks for your input, and I hope to hear more from you all.

Nov 15 '05 #6
> 1) instantiate a user object, set appropriate fields and call a
user.save()
method
2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately
3) instantiate a user object, usrMyUser, set appropriate fields, instantiate a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)


Yes, it is pretty off-topic uet challenging to step in.

If "User" represents a person using the system it will always have to be a
representation of data. Seeing the user object as an encapsulation of the
actual user is like saying "software technology has progressed that far
today, we don't need real users anymore, they have now been modelled and
automated". It is a nice thought (after all we all hate users, they are a
pain in the ass most of the time) but I don't think we will get away with
it. The first method for such a user object I can think of would be Login().
The second would be CallSupportAndComplain(). Enough of that.

The real user is the actor. He acts, the system responds. The system only
has information (data) about the user. Therefore I would first suggest
naming the object UserData (presuming we want to have an object for this
user data). UserData may comprise Preferences, History, AddressInformation
and more of these sub-objects. Wrapping this into an object seems like a
good idea if the application is "user centric" in some way, like some sort
of people directory.

The way data is best persisted seems all to depend on the technology used.
If each user has his own data file it may be read at login and written as a
unit when the user presses a Save button. If some client-server database
technology is user in which data items are stored in tables in a relational
manner, one may want to split things up and not work against the grain and
offer properties one page at atime with the ability to save them one page at
a time.

Regardless of technology, transparent persistence could be nice but the UI
would have to make it clear that changes are instant, users may not be used
to it. If data were in SQL Server it probably wouldn't hurt much
performancewise to have one transaction per change, if it is little data .
It will be queued and written back soon, how many users could possibly be
changing their settings at the same time? It will not likely be an issue,
the round-trip over the internet (in case of a web application) and the
effect on the user experience will be of greater concern.

The idea of having a storage interface as someone else suggested (modern
times serialization) could be a nice way of isolating your object from the
underlying storage mechanism (being an XML file, an SQL Server database or
whatever). If portability and store-independency is an issue it is a valid
idea.

Martin.
Nov 15 '05 #7
Interesting subject, that raises many questions (maybe too many). Here are
some thoughts:

* Does your user object represent a copy of data about a user, or does it
represent the user him/herself.

I would answer: it represents "partial information about the user
him/herself".

The user him/herself is made of flesh and bone and (fortunately) there is no
way to represent the entire user (with all his cells) into the computer.
This remark may sound obvious but at least it puts some boundaries on what
we can "represent" inside a computer.

When the information is really related to the fleshy nature of the user (for
example, his body temperature), the real data belongs to the real user and
the computer always has a copy, which is always out-of-date (could be only
by a few seconds but anyway it will be out of date!).

Otherwise, when the information is more "administrative" (his social
security number, his salary, etc.), the real data is probably more in the
computer than in the body cells these days. In this case, there is usually
some "reference database" from which we are expecting to get accurate data.
So, the real data is the data in the reference database, and everything else
is a copy, which may or may not be up-to-date.

So, to summarize this view, the real user is not in the reference database,
but the reference database is usually the source for some partial
information about the user, and every other copy of this information is just
a copy, which may or may not be up-to-date.

* How do we edit this information (scenarios 1, 2, 3)?

Things are not as simple as you present them, and I think that two important
notions must be taken into consideration:

a) TRANSACTIONS: saving properties one by one is a very simplistic approach.
In most business contexts, the database can only be updated after some
validation rules have been applied. These validation rules usually span over
several properties, and often, they even span over several objects. So,
often, you cannot even update a single object in isolation, you have to
update several objects together, and you have to make sure that this update
operation is treated in an atomic way with respect to the queries that other
agents may perform against the database. In short, you need transaction
semantics.

b) CONCURRENCY: The data that you have in your web interface is only a copy,
and someone may be modifying the reference database while you are editing
your copy (unless, you have placed a lock on the object in the database,
which is almost impossible to do in a web context because it is a
disconnected context). So, you need CONFLICT RESOLUTION rules to handle
that.

With this in mind, the scenarios that you propose can be analyzed as
follows:

1) OK for transactions that deal with a single object. Conflict resolution
is simplistic: last one who writes wins (unless your save logic is more
sophisticated and deals with conflicts).

2) Only ok if the validation rules are simplistic (properties validated
independently from each other), does not support transactions, nor any
sophisticated form of conflict resolution. This is also terribly
inefficient.

3) You are in better shape. Workflow can build transactions and handle
conflict resolution. Usually, you need a way to loop back to the UI if the
workflow detects a validation error or a conflict that it cannot solve
automatically.

Bruno.
"designconcepts" <th*********@hotmail.com> a écrit dans le message de
news:%2****************@TK2MSFTNGP09.phx.gbl...
bo'jour, bo'jour,
So I have question to present to the forum about OOD. This is a Csharp
forum, but C# is the lang of choice and the question is an exercise based on some comments by the chief designer of C#. Those of you who are junkies for design principle might be interested in contributing to this thread.

I was recently reading some interviews with the chief engineer for C#
(formerly Mr. Delphi), and he made an interesting comment about how you use objects as representations, and the path you choose in this respect has a
big impact on the way you write code. For instance, does your user object
represent a copy of data about a user or does it represent the user
him/herself?

This made me think about how we represent users in web applications.

Scenario: web application lets users change information about themselves
(address, billing info, etc), information about each is in persistent
storage somewhere. Web form has fields for address information and a 'save' button that does the obvious.

The question is this:
Do you:
1) instantiate a user object, set appropriate fields and call a user.save() method
2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately
2) instantiate a user object, usrMyUser, set appropriate fields, instantiate a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)

Each possibility represents a different way of looking at the user object
(as an avatar for the real user vs. a representation of user information).
If the user object is a representation of user information, in theory it
wouldn't have any methods, simply properties and be nothing more than a
custom data type. If the user object is an avatar, it will come at the price of efficiency and maintainability (you'll be making more calls to the data
store, and the entity itself will be interacting with data directly rather
than having a workflow object pass the entity through various stages of
processing).

I think this is a legitimate question about design technique, but if you
think I'm missing something obvious, please let me know. I'd like to see a
conversation develop about the pros and cons to each approach or new
approaches I haven't mentioned here. I've got definite critical opinions
about each of the options mentioned above, but I'll wait to point them out
in a follow-up if this post is successful in starting a thread.

Thanks for your input, and I hope to hear more from you all.


Nov 15 '05 #8
Thanks for the reply Martin,
I'm really interested in your point about the object being 'userdata' rather
than a 'user' -- the problem I've had with having methods to represent user
actions (such as user.save()) is that the whole framework surrounding a web
page already provides that representation of the actor, right? When he
clicks on a save button, that _is_ the real User "object"'s save method, if
it's safe to think that way. In other words, my problem with solution 1 was
that the following code:

private void btnSave_Click(object sender, System.EventArgs e) {
User usrCurrent = new
User(intSpecificUserIdForThePurposesOfReconstructi on);
usrCurrent.someProperty = someNewValue;
usrCurrent.Save();
}

seems very redundant, no?

I see more than a couple things are wrong there, but for the sake of
brevity:
* why should I repopulate the user object when all I'm doing is updating one
field and saving it?
* how do I know what's changed? This will manifest as inefficiencies.

So as you said, I think it's better, or at least more consistent, to have
our objects represent UserData rather than a User with real-life methods.

Still, how do we know what's changed? I think you also hit the nail on the
head by saying information about a user should be broken up, not only to aid
in clarity on the presentation layer, but also to help us know what's being
changed. With this scenario it's much easier to think of using workflow
objects. For instance, a UserManager object might have distinct methods for
managing this data, such as SaveHomeAddress(UserData usrCurrent),
SaveContactInfo(UserData usrCurrent), or SaveName(UserData usrCurrent).
Retrieving user data could also make use of a "UserManager" class with
methods like GetUser(int intUserId).

You could ask, 'why not just put the save methods on the user object?', such
as usrThisUser.SaveName(), or usrThisUser.SaveAddress(), but I think it's
important to have some symmetry in how we retrieve and save. For instance,
it would make sense to say UserManager.getUser(int intUserId), but would
create a paradox to say usrThisUser.getUser(int intUserId).

So now the problem with workflow objects. What happens when the user want to
make a payment, for instance? Assuming it's best to have a atomic workflows,
we wouldn't use the UserManager object to make a payment. We'd have to use a
PaymentManager to make a payment, passing it perhaps a User object and a
Payment object? I'm not positive what my problem is with this, but in
thinking it out into a larger environment with many avenues to go down, I
can foresee an application whose only 'true' objects are these large
battleship managers, who essentially only throw around custom data types. Is
this bad? I don't know, but something seems wrong to me.

It spins me in a circle to ask if perhaps we shouldn't go back to a User
object that has Managers within it.. In this case, we'd be saying
User.UserManager.SaveContactInfo(), or
User.PaymentManager.MakePayment(Payment myNewPayment).

Is this an appropriate way to look at things? Does it satisfy an assumed
need to have layer A, in this case the User class, completely ignorant of
layer C, the data access class? Do we care? Would it mean that everything
would fly around a User object again? How does it avoid the redundancy cited
above? I think one big difference is that the User object is now decidedly
acting as an agent or solicitor for the 'flesh-and-bones' user, implicitly
giving context to the managers. I'm not sure this is better.

Any thoughts?

"Martin Maat [EBL]" <du***@somewhere.nl> wrote in message
news:10*************@corp.supernews.com...
1) instantiate a user object, set appropriate fields and call a user.save()
method
2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately
3) instantiate a user object, usrMyUser, set appropriate fields,

instantiate
a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)


Yes, it is pretty off-topic uet challenging to step in.

If "User" represents a person using the system it will always have to be a
representation of data. Seeing the user object as an encapsulation of the
actual user is like saying "software technology has progressed that far
today, we don't need real users anymore, they have now been modelled and
automated". It is a nice thought (after all we all hate users, they are a
pain in the ass most of the time) but I don't think we will get away with
it. The first method for such a user object I can think of would be

Login(). The second would be CallSupportAndComplain(). Enough of that.

The real user is the actor. He acts, the system responds. The system only
has information (data) about the user. Therefore I would first suggest
naming the object UserData (presuming we want to have an object for this
user data). UserData may comprise Preferences, History, AddressInformation
and more of these sub-objects. Wrapping this into an object seems like a
good idea if the application is "user centric" in some way, like some sort
of people directory.

The way data is best persisted seems all to depend on the technology used.
If each user has his own data file it may be read at login and written as a unit when the user presses a Save button. If some client-server database
technology is user in which data items are stored in tables in a relational manner, one may want to split things up and not work against the grain and
offer properties one page at atime with the ability to save them one page at a time.

Regardless of technology, transparent persistence could be nice but the UI
would have to make it clear that changes are instant, users may not be used to it. If data were in SQL Server it probably wouldn't hurt much
performancewise to have one transaction per change, if it is little data .
It will be queued and written back soon, how many users could possibly be
changing their settings at the same time? It will not likely be an issue,
the round-trip over the internet (in case of a web application) and the
effect on the user experience will be of greater concern.

The idea of having a storage interface as someone else suggested (modern
times serialization) could be a nice way of isolating your object from the
underlying storage mechanism (being an XML file, an SQL Server database or
whatever). If portability and store-independency is an issue it is a valid
idea.

Martin.

Nov 15 '05 #9
Thanks for the reply Bruno, I just replied to Martin's email, and it's
2:15am, so I gotta hit the sack.. I'm going to try and post tomorrow, as
your email did give me some thoughts about the impact of transactional
integrity and concurrency I'd like to share.
You seemed to favor the workflow object in your post, and indeed,
Microsoft's documents (Patterns & Practices) often make mention of workflow
objects. Could you read the post Martin supplied + my response and weigh in
on that as well? Curious to know your opinion. In the meantime, I'm going to
get some sleep, do some work, drink a Friday margarita, then reply to your
post below. Have a good weekend!

"Bruno Jouhier [MVP]" <bj******@club-internet.fr> wrote in message
news:Ok**************@TK2MSFTNGP12.phx.gbl...
Interesting subject, that raises many questions (maybe too many). Here are
some thoughts:

* Does your user object represent a copy of data about a user, or does it
represent the user him/herself.

I would answer: it represents "partial information about the user
him/herself".

The user him/herself is made of flesh and bone and (fortunately) there is no way to represent the entire user (with all his cells) into the computer.
This remark may sound obvious but at least it puts some boundaries on what
we can "represent" inside a computer.

When the information is really related to the fleshy nature of the user (for example, his body temperature), the real data belongs to the real user and
the computer always has a copy, which is always out-of-date (could be only
by a few seconds but anyway it will be out of date!).

Otherwise, when the information is more "administrative" (his social
security number, his salary, etc.), the real data is probably more in the
computer than in the body cells these days. In this case, there is usually
some "reference database" from which we are expecting to get accurate data. So, the real data is the data in the reference database, and everything else is a copy, which may or may not be up-to-date.

So, to summarize this view, the real user is not in the reference database, but the reference database is usually the source for some partial
information about the user, and every other copy of this information is just a copy, which may or may not be up-to-date.

* How do we edit this information (scenarios 1, 2, 3)?

Things are not as simple as you present them, and I think that two important notions must be taken into consideration:

a) TRANSACTIONS: saving properties one by one is a very simplistic approach. In most business contexts, the database can only be updated after some
validation rules have been applied. These validation rules usually span over several properties, and often, they even span over several objects. So,
often, you cannot even update a single object in isolation, you have to
update several objects together, and you have to make sure that this update operation is treated in an atomic way with respect to the queries that other agents may perform against the database. In short, you need transaction
semantics.

b) CONCURRENCY: The data that you have in your web interface is only a copy, and someone may be modifying the reference database while you are editing
your copy (unless, you have placed a lock on the object in the database,
which is almost impossible to do in a web context because it is a
disconnected context). So, you need CONFLICT RESOLUTION rules to handle
that.

With this in mind, the scenarios that you propose can be analyzed as
follows:

1) OK for transactions that deal with a single object. Conflict resolution
is simplistic: last one who writes wins (unless your save logic is more
sophisticated and deals with conflicts).

2) Only ok if the validation rules are simplistic (properties validated
independently from each other), does not support transactions, nor any
sophisticated form of conflict resolution. This is also terribly
inefficient.

3) You are in better shape. Workflow can build transactions and handle
conflict resolution. Usually, you need a way to loop back to the UI if the
workflow detects a validation error or a conflict that it cannot solve
automatically.

Bruno.
"designconcepts" <th*********@hotmail.com> a écrit dans le message de
news:%2****************@TK2MSFTNGP09.phx.gbl...
bo'jour, bo'jour,
So I have question to present to the forum about OOD. This is a Csharp
forum, but C# is the lang of choice and the question is an exercise based
on
some comments by the chief designer of C#. Those of you who are junkies

for
design principle might be interested in contributing to this thread.

I was recently reading some interviews with the chief engineer for C#
(formerly Mr. Delphi), and he made an interesting comment about how you

use
objects as representations, and the path you choose in this respect has

a big impact on the way you write code. For instance, does your user object represent a copy of data about a user or does it represent the user
him/herself?

This made me think about how we represent users in web applications.

Scenario: web application lets users change information about themselves
(address, billing info, etc), information about each is in persistent
storage somewhere. Web form has fields for address information and a

'save'
button that does the obvious.

The question is this:
Do you:
1) instantiate a user object, set appropriate fields and call a

user.save()
method
2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately
2) instantiate a user object, usrMyUser, set appropriate fields,

instantiate
a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)

Each possibility represents a different way of looking at the user object (as an avatar for the real user vs. a representation of user information). If the user object is a representation of user information, in theory it
wouldn't have any methods, simply properties and be nothing more than a
custom data type. If the user object is an avatar, it will come at the

price
of efficiency and maintainability (you'll be making more calls to the data store, and the entity itself will be interacting with data directly rather than having a workflow object pass the entity through various stages of
processing).

I think this is a legitimate question about design technique, but if you
think I'm missing something obvious, please let me know. I'd like to see a conversation develop about the pros and cons to each approach or new
approaches I haven't mentioned here. I've got definite critical opinions
about each of the options mentioned above, but I'll wait to point them out in a follow-up if this post is successful in starting a thread.

Thanks for your input, and I hope to hear more from you all.


Nov 15 '05 #10
Thanks for the reply Mark. I think that's an awesome concept -- the
IPersistable interface. How would you deal with the inefficiencies of
(re)saving every field in the persistable object when only one field has
been modified, for instance? Would you just use a Commit() stub that would
be called after work is done, perhaps referencing private boolean
isPropertyModified values (tweaked from within the set handlers) to
determine what would need to be saved? Also, it would seem that to make this
flexible enough to be workable, you'd need to put a lot of effort into
mapping each value for each object to a relational model. I know we do this
anyway in effect, but it always seems oriented around particular tasks. In
other words, it seems like it would be easier if you were willing to resave
entire objects at the sacrifice of efficiency (in the situation where only
one property out of twenty-fie has changed). Would you agree with this, or
am I making it more complicated than it needs to be? How would you maintain
the efficiencies of only updating what _needs_ to be updated?

"Mark mm" <ma********@hotmail.com> wrote in message
news:MP************************@News.CIS.DFN.DE...
In article <#N**************@TK2MSFTNGP09.phx.gbl>,
th*********@hotmail.com says...
bo'jour, bo'jour,
So I have question to present to the forum about OOD. This is a Csharp
forum, but C# is the lang of choice and the question is an exercise based on some comments by the chief designer of C#. Those of you who are junkies for design principle might be interested in contributing to this thread.

I was recently reading some interviews with the chief engineer for C#
(formerly Mr. Delphi), and he made an interesting comment about how you use objects as representations, and the path you choose in this respect has a big impact on the way you write code. For instance, does your user object represent a copy of data about a user or does it represent the user
him/herself?

This made me think about how we represent users in web applications.

Scenario: web application lets users change information about themselves
(address, billing info, etc), information about each is in persistent
storage somewhere. Web form has fields for address information and a 'save' button that does the obvious.

The question is this:
Do you:
1) instantiate a user object, set appropriate fields and call a user.save() method
2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately
2) instantiate a user object, usrMyUser, set appropriate fields, instantiate a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)

Each possibility represents a different way of looking at the user object (as an avatar for the real user vs. a representation of user information). If the user object is a representation of user information, in theory it
wouldn't have any methods, simply properties and be nothing more than a
custom data type. If the user object is an avatar, it will come at the price of efficiency and maintainability (you'll be making more calls to the data store, and the entity itself will be interacting with data directly rather than having a workflow object pass the entity through various stages of
processing).

I think this is a legitimate question about design technique, but if you
think I'm missing something obvious, please let me know. I'd like to see a conversation develop about the pros and cons to each approach or new
approaches I haven't mentioned here. I've got definite critical opinions
about each of the options mentioned above, but I'll wait to point them out in a follow-up if this post is successful in starting a thread.

Thanks for your input, and I hope to hear more from you all.


I'm my opinion,
1) instantiate a user object, set appropriate fields and call a
user.save() method

This is a simple representation and maps the web form more.

2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately

This does put all of the Users's responsibility in the it's class, but
for effiency reasons it would have to use a buffer (See below)

3) instantiate a user object, usrMyUser, set appropriate fields,
instantiate a workflow object for a UserManager (for instance) and
call UserManager.SaveUser(usrMyUser)

A command object, more efficient but not much different that 1). And
puts the responsibility away from the User.

If you have a IPersistable interface and let any class that needs to
save itself implement that. Then that allows you to have a buffer of
some sort, so when a change occurs in User (or any IPersistable) you can
add this to a collection of IPersitable objects and go through them
calling Save at a more convenient time. This of course involves another
class, but in the Data Layer. Perhaps called Persist, with a collection
of IPersistables.

Sorry for rabbiting on, this was just another way you could design this
in C#. I think in real world you have to balance effiency and also keep
a good OO design.
--
Thanks
Mark mm

Nov 15 '05 #11
*strokes goatee thoughtfully*
So where would you autosave? I'm ignorant of the way the Stream.Flush()
works, and ordinarily I'd look it up before posting this, but it's getting
really late for me here.. Are you saying that each object, such as a User
object, would also need a Close() method, or were you thinking about adding
this in the Dispose method, or somesuch? I guess I'm thinking if that we
make a requirement of calling a Close method for a User object, how would it
be different than just calling a Save method? Err..that is to say, where
would the autosave get triggered? Sounds cool, just curious about
implementation..
Thanks!

<di********@discussion.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Have an .AutoSave property , if thats set, update the persistant storage for every propset. if its false, require a .save() call.

Thats how Stream.Flush() works, you have .AutoFlush = true | false; and you can call .Flush() if you desure. Its also called on .Close(),

"Mark mm" <ma********@hotmail.com> wrote in message
news:MP************************@News.CIS.DFN.DE...
In article <#N**************@TK2MSFTNGP09.phx.gbl>,
th*********@hotmail.com says...
bo'jour, bo'jour,
So I have question to present to the forum about OOD. This is a Csharp
forum, but C# is the lang of choice and the question is an exercise based on some comments by the chief designer of C#. Those of you who are junkies
for
design principle might be interested in contributing to this thread.

I was recently reading some interviews with the chief engineer for C#
(formerly Mr. Delphi), and he made an interesting comment about how
you
use objects as representations, and the path you choose in this respect
has
a big impact on the way you write code. For instance, does your user object represent a copy of data about a user or does it represent the user
him/herself?

This made me think about how we represent users in web applications.

Scenario: web application lets users change information about
themselves (address, billing info, etc), information about each is in persistent
storage somewhere. Web form has fields for address information and a
'save' button that does the obvious.

The question is this:
Do you:
1) instantiate a user object, set appropriate fields and call a user.save() method
2) instantiate a user object, and each time you set a property, the set handler updates the persistent storage immediately
2) instantiate a user object, usrMyUser, set appropriate fields, instantiate a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)

Each possibility represents a different way of looking at the user object (as an avatar for the real user vs. a representation of user information). If the user object is a representation of user information, in theory it wouldn't have any methods, simply properties and be nothing more than a custom data type. If the user object is an avatar, it will come at the price of efficiency and maintainability (you'll be making more calls to the data store, and the entity itself will be interacting with data directly rather than having a workflow object pass the entity through various stages of processing).

I think this is a legitimate question about design technique, but if you think I'm missing something obvious, please let me know. I'd like to see a
conversation develop about the pros and cons to each approach or new
approaches I haven't mentioned here. I've got definite critical
opinions about each of the options mentioned above, but I'll wait to point them

out in a follow-up if this post is successful in starting a thread.

Thanks for your input, and I hope to hear more from you all.


I'm my opinion,
1) instantiate a user object, set appropriate fields and call a
user.save() method

This is a simple representation and maps the web form more.

2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately

This does put all of the Users's responsibility in the it's class, but
for effiency reasons it would have to use a buffer (See below)

3) instantiate a user object, usrMyUser, set appropriate fields,
instantiate a workflow object for a UserManager (for instance) and
call UserManager.SaveUser(usrMyUser)

A command object, more efficient but not much different that 1). And
puts the responsibility away from the User.

If you have a IPersistable interface and let any class that needs to
save itself implement that. Then that allows you to have a buffer of
some sort, so when a change occurs in User (or any IPersistable) you can
add this to a collection of IPersitable objects and go through them
calling Save at a more convenient time. This of course involves another
class, but in the Data Layer. Perhaps called Persist, with a collection
of IPersistables.

Sorry for rabbiting on, this was just another way you could design this
in C#. I think in real world you have to balance effiency and also keep
a good OO design.
--
Thanks
Mark mm


Nov 15 '05 #12
hey, thanks for the book tip Relu.. I dig those pattern books, but have yet
to find one that spoke to me about this issue, though I must say I've never
read one cover-to-cover. :)
Thanks again!
Also, since you said you preferred the third option, would you mind taking a
look at the reply by Martin Maat and weighing in on that discussion?
"Georgescu Aurelian" <re**@itprovision.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Hello,

I prefer the 3rd option, it gives you a clear separation of the jobs, and
this way bloated classes are avoided.
A very good book treating all this aspects and much more is:
Patterns of Enterprise Application Architecture (Addison Wesley)
By Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee,
Randy Stafford

Best regards,
Relu.
"designconcepts" <th*********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
bo'jour, bo'jour,
So I have question to present to the forum about OOD. This is a Csharp
forum, but C# is the lang of choice and the question is an exercise based
on
some comments by the chief designer of C#. Those of you who are junkies

for
design principle might be interested in contributing to this thread.

I was recently reading some interviews with the chief engineer for C#
(formerly Mr. Delphi), and he made an interesting comment about how you

use
objects as representations, and the path you choose in this respect has

a big impact on the way you write code. For instance, does your user object represent a copy of data about a user or does it represent the user
him/herself?

This made me think about how we represent users in web applications.

Scenario: web application lets users change information about themselves
(address, billing info, etc), information about each is in persistent
storage somewhere. Web form has fields for address information and a

'save'
button that does the obvious.

The question is this:
Do you:
1) instantiate a user object, set appropriate fields and call a

user.save()
method
2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately
2) instantiate a user object, usrMyUser, set appropriate fields,

instantiate
a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)

Each possibility represents a different way of looking at the user object (as an avatar for the real user vs. a representation of user information). If the user object is a representation of user information, in theory it
wouldn't have any methods, simply properties and be nothing more than a
custom data type. If the user object is an avatar, it will come at the

price
of efficiency and maintainability (you'll be making more calls to the data store, and the entity itself will be interacting with data directly rather than having a workflow object pass the entity through various stages of
processing).

I think this is a legitimate question about design technique, but if you
think I'm missing something obvious, please let me know. I'd like to see a conversation develop about the pros and cons to each approach or new
approaches I haven't mentioned here. I've got definite critical opinions
about each of the options mentioned above, but I'll wait to point them out in a follow-up if this post is successful in starting a thread.

Thanks for your input, and I hope to hear more from you all.


Nov 15 '05 #13
Hello,

I hope you will find time to read that book, it may gives you a lot of
answears (also the .net aproach is present there)...

I did have a look over the reply by Martin Maat, and maybe it will be
intersting for you to tell you why I take the 3rd option. First I'm used to
follow more patterns when designing the objects. There are some things that
I'm aware when designing the objects and the user interface (it involves a
little more work but this is ok for me, because I like to have a coerent
user interface).

* normally a dialog would have a OK and Cancel button. This gives me the
impression that changes will be persisted only if a press the OK button. The
Cancel should do the work that was designed to do: to cancel all the
modifications, no matter what the user have done. Second only the data that
was really changed should be updated (this seems to me to be the User
object's job), after this is quite easy to implement an Undo feature (the
User nows what changed and what was before).
* the bussiness rules are present on the User object, for example
ComputePayment or other things... For me the fact that the user data will be
eventually persisted into a database is not a bussiness rule, is just a
persistance issue.
* sometimes i use collections to keep more items in memory, but since
sometimes may be inefficient to have a lot of data in memory, and if you
want to compute some things from a large set i prefer to have a second
object with a method that gets an argument to an enumerator (for example)
interface. If I have a separate layer for saving i can add very easily an
option to copy data to clipboard, to save to a delimited tab file... and the
possibilites can go....
* i prefer a separate layer for saving and loading instances because it can
happens that i have a custom security implementation and i really don't want
to embeed that logic in User object.
The list could continue but I will take a break, for the moment... :)

Best regards,
Relu.
"designconcepts" <th*********@hotmail.com> wrote in message
news:uC**************@TK2MSFTNGP11.phx.gbl...
hey, thanks for the book tip Relu.. I dig those pattern books, but have yet to find one that spoke to me about this issue, though I must say I've never read one cover-to-cover. :)
Thanks again!
Also, since you said you preferred the third option, would you mind taking a look at the reply by Martin Maat and weighing in on that discussion?
"Georgescu Aurelian" <re**@itprovision.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Hello,

I prefer the 3rd option, it gives you a clear separation of the jobs, and
this way bloated classes are avoided.
A very good book treating all this aspects and much more is:
Patterns of Enterprise Application Architecture (Addison Wesley)
By Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford

Best regards,
Relu.
"designconcepts" <th*********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
bo'jour, bo'jour,
So I have question to present to the forum about OOD. This is a Csharp
forum, but C# is the lang of choice and the question is an exercise based
on
some comments by the chief designer of C#. Those of you who are junkies for
design principle might be interested in contributing to this thread.

I was recently reading some interviews with the chief engineer for C#
(formerly Mr. Delphi), and he made an interesting comment about how
you use
objects as representations, and the path you choose in this respect
has a big impact on the way you write code. For instance, does your user object represent a copy of data about a user or does it represent the user
him/herself?

This made me think about how we represent users in web applications.

Scenario: web application lets users change information about
themselves (address, billing info, etc), information about each is in persistent
storage somewhere. Web form has fields for address information and a 'save'
button that does the obvious.

The question is this:
Do you:
1) instantiate a user object, set appropriate fields and call a

user.save()
method
2) instantiate a user object, and each time you set a property, the set handler updates the persistent storage immediately
2) instantiate a user object, usrMyUser, set appropriate fields,

instantiate
a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)

Each possibility represents a different way of looking at the user

object (as an avatar for the real user vs. a representation of user information). If the user object is a representation of user information, in theory it wouldn't have any methods, simply properties and be nothing more than a custom data type. If the user object is an avatar, it will come at the

price
of efficiency and maintainability (you'll be making more calls to the data store, and the entity itself will be interacting with data directly rather than having a workflow object pass the entity through various stages of processing).

I think this is a legitimate question about design technique, but if you think I'm missing something obvious, please let me know. I'd like to see a
conversation develop about the pros and cons to each approach or new
approaches I haven't mentioned here. I've got definite critical
opinions about each of the options mentioned above, but I'll wait to point them

out in a follow-up if this post is successful in starting a thread.

Thanks for your input, and I hope to hear more from you all.



Nov 15 '05 #14
> private void btnSave_Click(object sender, System.EventArgs e) {
User usrCurrent = new
User(intSpecificUserIdForThePurposesOfReconstructi on);
usrCurrent.someProperty = someNewValue;
usrCurrent.Save();
}

seems very redundant, no?
If you were to have an all-encapsulating-suck-it-all-up-at-creation-time
user object you would of course not instantiate it on the fly whenever you
need some of its functionality. You would create it at logon and drop it
(perhaps persist it if you chose the write behind caching approach) at
logoff time.
Still, how do we know what's changed?
Just for the sake of argument, if you would choose the all-in-one
encapsulation model we just discussed you should not be bothered with
keeping track of which data elements have changed. You should treat it
symmetricly. If you read everything in one go regardless of what may be
needed, you will write everything too regardless of what had changed. The
point is whether your object is "dirty" or not. If Dirty you save (the lot),
if not dirty you do not save. It is just like a Word document.

This would still allow you to present pages to the user that can be applied
separately. The pages however will be saved to the object effectively
rendering it dirty so it will be saved later.
I can foresee an application whose only 'true' objects are
these large battleship managers, who essentially only throw
around custom data types. Is this bad? I don't know, but
something seems wrong to me.
Managers are typically simple (!). The OO-term for a manager is an agent and
an agent basically talks to objects in order to get something done. That is
why the agent itself does not have to be intelligent or capable (the analogy
gets stronger and stronger), they basically contain scripts, spit some buzz
words if you will to get the problem domain objects working.

So if your managers start to grow that would definiately be an indicator of
design going bad.
Is this an appropriate way to look at things? Does it satisfy an assumed
need to have layer A, in this case the User class, completely ignorant of
layer C, the data access class? Would it mean that everything would fly around a User object
again? How does it avoid the redundancy cited above? I think
one big difference is that the User object is now decidedly
acting as an agent or solicitor for the 'flesh-and-bones' user,
implicitly giving context to the managers. I'm not sure this is
better.


You are so scared to miss anything that you evaluate every concept you are
aware of or are pointed to. That is good but when you feel a concept is
realy hard to understand, if it doesn't make things easier for you, if you
don't succeed in mapping it into your problem, it may be because your
problem is just not complicated enough for the pattern to apply. This would
be a good thing. Just beware you're not searching for problems to solutions.
Agents can be a good thing but you may not need them for they may not have
anything usefull to do. If it isn't obvious what the agent could contribute,
don't use it. Using patterns from the start that do not apply is worse than
just starting off and build your system until you feel the need for a
solution to a problem. Once you feel the problem the solution is likely to
be more obvious and it will be easier to map the right pattern onto it.

Martin.
Nov 15 '05 #15
> private void btnSave_Click(object sender, System.EventArgs e) {
User usrCurrent = new
User(intSpecificUserIdForThePurposesOfReconstructi on);
usrCurrent.someProperty = someNewValue;
usrCurrent.Save();
}

seems very redundant, no?
If you were to have an all-encapsulating-suck-it-all-up-at-creation-time
user object you would of course not instantiate it on the fly whenever you
need some of its functionality. You would create it at logon and drop it
(perhaps persist it if you chose the write behind caching approach) at
logoff time.
Still, how do we know what's changed?
Just for the sake of argument, if you would choose the all-in-one
encapsulation model we just discussed you should not be bothered with
keeping track of which data elements have changed. You should treat it
symmetricly. If you read everything in one go regardless of what may be
needed, you will write everything too regardless of what had changed. The
point is whether your object is "dirty" or not. If Dirty you save (the lot),
if not dirty you do not save. It is just like a Word document.

This would still allow you to present pages to the user that can be applied
separately. The pages however will be saved to the object effectively
rendering it dirty so it will be saved later.
I can foresee an application whose only 'true' objects are
these large battleship managers, who essentially only throw
around custom data types. Is this bad? I don't know, but
something seems wrong to me.
Managers are typically simple (!). The OO-term for a manager is an agent and
an agent basically talks to objects in order to get something done. That is
why the agent itself does not have to be intelligent or capable (the analogy
gets stronger and stronger), they basically contain scripts, spit some buzz
words if you will to get the problem domain objects working.

So if your managers start to grow that would definiately be an indicator of
design going bad.
Is this an appropriate way to look at things? Does it satisfy an assumed
need to have layer A, in this case the User class, completely ignorant of
layer C, the data access class? Would it mean that everything would fly around a User object
again? How does it avoid the redundancy cited above? I think
one big difference is that the User object is now decidedly
acting as an agent or solicitor for the 'flesh-and-bones' user,
implicitly giving context to the managers. I'm not sure this is
better.


You are so scared to miss anything that you evaluate every concept you are
aware of or are pointed to. That is good but when you feel a concept is
realy hard to understand, if it doesn't make things easier for you, if you
don't succeed in mapping it into your problem, it may be because your
problem is just not complicated enough for the pattern to apply. This would
be a good thing. Just beware you're not searching for problems to solutions.
Agents can be a good thing but you may not need them for they may not have
anything usefull to do. If it isn't obvious what the agent could contribute,
don't use it. Using patterns from the start that do not apply is worse than
just starting off and build your system until you feel the need for a
solution to a problem. Once you feel the problem the solution is likely to
be more obvious and it will be easier to map the right pattern onto it.

Martin.
Nov 15 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Jukka K. Korpela | last post: by
reply views Thread by Janis Jekabsons | last post: by
3 posts views Thread by Henry | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by Gurmeet2796 | last post: by
reply views Thread by mdpf | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.