OOD理论问题 [英] OOD theory question
问题描述
bo''jour，bo''jour，
所以我有问题要向论坛介绍OOD。这是一个Csharp
论坛，但C＃是首选的问题，问题是基于这个练习基于
C＃首席设计师的一些评论。那些擅长设计原则的人可能会对这个帖子做出贡献。
我最近正在阅读C＃总工程师的一些采访
（以前是Delphi先生），他就如何使用
对象作为表示做了一个有趣的评论，你在这方面选择的路径有一个
对编写代码的方式有很大影响。例如，您的用户对象
是代表用户数据的副本还是代表用户
他/她自己？
这让我想到了我们如何在Web应用程序中代表用户。
场景：Web应用程序允许用户更改自己的信息
（地址，账单信息等），关于每个的信息都在某个地方持久存储。 Web表单包含地址信息字段和保存
按钮，显而易见。
问题是：
你是否：
1）实例化用户对象，设置适当的字段并调用user.save（）
方法
2 ）实例化一个用户对象，每次设置一个属性时，set
处理程序立即更新持久存储
2）实例化用户对象usrMyUser，设置相应的字段，实例化
a UserManager的工作流对象（例如）并调用
UserManager.SaveUser（usrMyUser）
每种可能性代表查看用户对象的另一种方式
（作为真实用户的头像与用户信息的表示）。
如果用户对象是表示用户信息，理论上它不会有任何方法，只是属性，只不过是一个自定义数据类型。如果用户对象是一个头像，它的价格将是
的效率和可维护性（你将更多地调用数据
商店，以及实体本身将直接与数据交互而不是让工作流对象通过实体通过
处理的各个阶段进行交互。
我认为这是一个关于设计技巧的合理问题，但如果你认为我错过了一些明显的东西，请告诉我。我希望看到一个
的对话，关于每种方法的优缺点或新的
方法，我在这里没有提到过。关于上面提到的每个选项，我都有明确的批评意见
，但如果这篇文章，我会等待他们指出
后续跟进成功开始一个帖子。
感谢您的意见，我希望能听到更多来自你们的信息。
在文章< #N ************** @ TK2MSFTNGP09.phx.gbl>，
th ********* @ hotmail.com 说...bo''jour，bo''jour，
所以我有问题要向论坛介绍OOD。这是一个Csharp
论坛，但是C＃是首选，而问题是基于C＃首席设计师的一些评论。你们这些擅长设计原则的人可能会对这个主题做出贡献。
我最近正在阅读一些关于C＃
（前任先生）的总工程师的采访。 Delphi），他就如何使用
对象作为表示做了一个有趣的评论，你在这方面选择的路径对你编写代码的方式有很大的影响。例如，您的用户对象是代表用户数据的副本还是代表用户他/她自己？
这让我想到我们如何代表用户在Web应用程序中。
场景：Web应用程序允许用户更改自己的信息
（地址，账单信息等），每个信息都存储在某个地方的持久性存储中。 Web表单包含地址信息字段和保存按钮，可以显示明显的内容。
问题是：
你是否：
1）实例化用户对象，设置适当的字段并调用user.save（）
方法2）实例化用户对象，每次设置属性时，set
处理程序更新持久化立即存储
2）实例化用户对象usrMyUser，设置相应的字段，实例化UserManager的工作流对象（例如）并调用
UserManager.SaveUser（usrMyUser）
每种可能性代表一种不同的方式来查看用户对象
（作为真实用户的化身与用户信息的表示）。
如果用户对象是用户的表示信息，理论上它没有任何方法，只是属性，只不过是一种自定义数据类型。如果用户对象是化身，它将以效率和可维护性为代价（您将更多地调用数据存储，实体本身将直接与数据交互）而不是让工作流对象通过处理的各个阶段传递实体。
我认为这是一个关于设计技术的合理问题，但如果你
我想我错过了一些明显的东西，请告诉我。我希望看到一个关于每种方法的利弊的讨论，或者我在这里没有提到的新方法。关于上面提到的每个选项，我都有明确的批评意见，但是如果这篇文章成功启动一个帖子，我会等待在后续内容中指出它们。感谢您的意见，我希望能听到更多来自大家的信息。
我是我的意见，
1）实例化一个用户对象，设置适当的字段并调用
user.save（）方法
这很简单表示和映射Web表单更多。
2）实例化一个用户对象，每次设置一个属性时，set
处理程序更新持久存储立即
这确实将所有用户的责任放在了它的课堂上，但是出于效率的原因，它必须使用一个用户的b $ b缓冲区（见下文）
3）实例化用户对象usrMyUser，设置适当的字段，
实例化UserManager的工作流对象（例如）和<无线电通信/>
调用UserManager.SaveUser（usrMyUser）
一个命令对象，效率更高但与1）相差无几。并且
将责任从用户处移开。
如果你有一个IPersistable接口，并且允许任何需要的课程
保存自己实现。然后，这允许你有某种类型的缓冲区
，所以当用户（或任何IPersistable）发生更改时，你可以将
添加到IPersitable对象的集合中并通过他们
呼叫在更方便的时间保存。这当然涉及另一个
类，但在数据层中。也许叫做Persist，有一个收集
的IPersistables。
对不起，这只是另一种你可以设计的方式
$ b C＃中的$ b。我认为在现实世界中你必须平衡效率并保持良好的OO设计。
-
谢谢
Mark mm
如果设置了.AutoSave属性，则更新每个propset的
的持久存储空间。如果它是假的，则需要一个.save（）调用。
这就是Stream.Flush（）如何工作，你有.AutoFlush = true |假;如果你愿意的话，你可以调用.Flush（）。它也被称为.Close（），
" Mark mm" <毫安******** @ hotmail.com>在消息中写道
新闻：MP ************************ @ News.CIS.DFN.DE ... < blockquote class =post_quotes>文章< #N ************** @ TK2MSFTNGP09.phx.gbl>，
th ********* @ hotmail.com 说...bo''jour，bo'' jour，
所以我有问题要向论坛介绍OOD。这是一个Csharp
论坛，但是C＃是首选，根据C＃首席设计师的一些评论，问题是练习
。那些喜欢设计原则的瘾君子
可能会对这个帖子做出贡献。
我最近正在阅读C＃
（前任先生）的总工程师的一些采访。 Delphi），他对你如何使用对象作为表示做了一个有趣的评论，你在这方面选择的路径对你编写代码的方式有很大的影响。例如，您的用户
对象是代表用户数据的副本还是代表用户他/她自己？
这让我想到我们如何代表用户在Web应用程序中。
场景：Web应用程序允许用户更改自己的信息
（地址，账单信息等），每个信息都存储在某个地方的持久性存储中。 Web表单包含地址信息字段和
''保存'按钮，显而易见。
问题是：
你是否：
1）实例化用户对象，设置适当的字段并调用
user.save（）方法
2）实例化用户对象，每次设置属性时，set
处理程序更新持久化立即存储
2）实例化用户对象usrMyUser，设置相应的字段，
实例化UserManager的工作流对象（例如）并调用
UserManager.SaveUser（usrMyUser）
每种可能性代表一种不同的方式来查看用户
对象（作为真实用户的头像与用户
信息的表示）。如果用户对象是用户信息的表示，理论上它不会有任何方法，只是属性，只不过是自定义数据类型。如果用户对象是化身，它将以
的效率和可维护性价格出现（你将对
数据存储进行更多调用，实体本身将直接与数据交互）
而不是让工作流对象通过
处理的各个阶段传递实体。
我认为这是一个关于设计技术的合理问题，但是如果你
我想我错过了一些明显的东西，请告诉我。我希望看到
一个关于每种方法的利弊的讨论，或者我在这里没有提到的新方法。我对上面提到的每个选项都有明确的批评意见，但是如果这篇文章成功启动一个帖子，我会等待他们在后续跟踪中给出
。 br />
感谢您的投入，我希望能听到更多来自你们。
我是我的看法，
1 ）实例化用户对象，设置适当的字段并调用
user.save（）方法
这是一个简单的表示形式，并更多地映射Web表单。
2）实例化一个用户对象，每次设置一个属性，set
处理程序立即更新持久存储
这确实将所有用户的责任放在了它'但是出于效率原因，它必须使用缓冲区（见下文）
3）实例化用户对象usrMyUser，设置适当的字段，
实例化UserManager的工作流对象（例如）和
调用UserManager.SaveUser（usrMyUser）
A co mmand对象，更高效，但没有太大的不同1）。并且
将责任放在远离用户的位置。
如果你有一个IPersistable接口，让任何需要保存自己的类实现它。然后，这允许您有某种缓冲区，所以当用户（或任何IPersistable）发生更改时，您可以将其添加到一组IPersitable对象并通过它们
在更方便的时间拨打保存。这当然涉及另一个类，但在数据层。也许叫做Persist，有一个IPersistables集合。
抱歉，这只是你可以用C＃设计这个
的另一种方式。我认为在现实世界中你必须平衡效率并保持良好的OO设计。
-
谢谢
Mark mm
<二******** @ discussion.microsoft.com>在留言中写道
新闻：％2 **************** @ TK2MSFTNGP09.phx.gbl ...有一个.AutoSave属性，如果设置，则更新每个propset的持久存储
。如果它是假的，需要一个.save（）调用。
效率低下。
你要改变5个属性，5个更新进入数据库。
令人印象深刻。
-
问候
Thomas Tomiczek
THONA Software&咨询有限公司
（微软MVP C＃/。NET）
（CTO PowerNodes Ltd.）
---
还在等待ObjectSpaces？今天是EntityBroker - 更多功能，
更强大。
现在正在使用的东西。对于你必须交付的项目 - 现在。
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.
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
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
<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.
这篇关于OOD理论问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
