人们做了什么来避免紧耦合？ [英] What do People do to avoid Tight Coupling?

问题描述

采用n层

系统的项目层次结构解决方案，以便我们拥有数据层，业务层和表示层。

表示层耦合到业务层，业务

层耦合到数据层。到目前为止一直很好。


假设数据层引发一个事件，它将Me（发送者）作为

对象和e（MyEventArgs， EventArgs的后代）到上面的层

（业务层）。假设业务层需要将此事件传递给表示层。它将我作为一个对象发送，但它是什么

它发送e作为？它不能作为MyEventArgs发送它，因为演示文稿

层对此类事物一无所知。我们可以将表示层

耦合到数据层，这样它就知道MyEventArgs是什么，但肯定是
是禁止的。


我们还可以将MyEventArgs的定义删除到另一个项目

哪一切都是耦合的，但是现在这个常见的项目面临着

的危险各种特定于个人的东西的折衷组合

项目。


我们可以定义MyEventArgs的业务层版本 - 实际上是

与数据层中的一个相同 - 并且在传递之前将每个元素复制到新的
对象，但这是很多打字，现在我们有了

重复。


我很想知道其他人在这种情况下做了什么。


Charles

Take a solution with a project hierarchy along the lines of an n-tier
system, so that we have a data layer, business layer and presentation layer.
The presentation layer is coupled to the business layer, and the business
layer is coupled to the data layer. So far so good.

Suppose the data layer raises an event, and it passes Me (the sender) as an
object, and e (MyEventArgs, a descendent of EventArgs) to the layer above
(the business layer). Suppose also that the business layer needs to pass
this event on to the presentation layer. It sends Me as an object, but what
does it send e as? It can''t send it as MyEventArgs because the presentation
layer knows nothing of such things. We could couple the presentation layer
to the data layer, so that it knows what a MyEventArgs is, but surely that
is a no-no.

We could also remove the definition of MyEventArgs to another project to
which everything is coupled, but now this common project is in danger of
being an eclectic mix of stuff that is really specific to individual
projects.

We could define a business layer version of MyEventArgs - which is actually
identical to the one in the data layer - and copy each element to the new
object before passing it on, but that is a lot of typing, and now we have
duplication.

I am interested to hear what other people do in this situation.

Charles

推荐答案

查尔斯，


而不是抽象地谈论具体的演示内容

layer nee d与数据层一起做出反应吗？


Dan


" Charles Law" < BL *** @ nowhere.com>在消息中写道

新闻：eB ************** @ tk2msftngp13.phx.gbl ...

Charles,

Rather then talking in the abstract what specifically does the presentation
layer need to react to in conjunction with the data layer?

Dan

"Charles Law" <bl***@nowhere.com> wrote in message
news:eB**************@tk2msftngp13.phx.gbl...

采取一个解决方案项目层次结构沿着n层系统，我们有一个数据层，业务层和表示
层。表示层耦合到业务层，业务层耦合到数据层。到目前为止一直很好。

假设数据层引发了一个事件，它将Me（发送者）作为
对象传递给e（MyEventArgs，一个EventArgs的后代）到该层上面
（业务层）。还假设业务层需要将此事件传递到表示层。它将我作为一个对象发送，但是
它发送的是什么？它不能作为MyEventArgs发送它，因为
表示层不知道这些事情。我们可以将表示层连接到数据层，以便它知道MyEventArgs是什么，但肯定是
是禁止的。

我们也可以删除将MyEventArgs定义为另一个项目，其中所有内容都是耦合的，但现在这个常见的项目面临着各种各样的项目的折衷组合的危险。

我们可以定义MyEventArgs的业务层版本 - 实际上是
与数据层中的相同 - 并在传递之前将每个元素复制到新的
对象，但是很多打字，现在我们有重复。

我很想知道其他人在这种情况下做了什么。

Charles

Take a solution with a project hierarchy along the lines of an n-tier
system, so that we have a data layer, business layer and presentation layer. The presentation layer is coupled to the business layer, and the business
layer is coupled to the data layer. So far so good.

Suppose the data layer raises an event, and it passes Me (the sender) as an object, and e (MyEventArgs, a descendent of EventArgs) to the layer above
(the business layer). Suppose also that the business layer needs to pass
this event on to the presentation layer. It sends Me as an object, but what does it send e as? It can''t send it as MyEventArgs because the presentation layer knows nothing of such things. We could couple the presentation layer
to the data layer, so that it knows what a MyEventArgs is, but surely that
is a no-no.

We could also remove the definition of MyEventArgs to another project to
which everything is coupled, but now this common project is in danger of
being an eclectic mix of stuff that is really specific to individual
projects.

We could define a business layer version of MyEventArgs - which is actually identical to the one in the data layer - and copy each element to the new
object before passing it on, but that is a lot of typing, and now we have
duplication.

I am interested to hear what other people do in this situation.

Charles

>假设数据层引发一个事件，它将Me（发送者）传递给

一个

> Suppose the data layer raises an event, and it passes Me (the sender) as
an

对象，并将e（MyEventArgs，一个EventArgs的后代）传递给上面的层
（业务层）。

object, and e (MyEventArgs, a descendent of EventArgs) to the layer above
(the business layer).

也许你应该就此止步。而不是将一个对象（或者更多的是具体的b $ b）传递回业务层，为什么不将一个

不同的对象或只是数据传递到业务层呢使用？

Perhaps you should stop there. Rather than passing an object (or more
specifically itself) back to the business layer, why not pass either a
different object or just data to the business layer for it to consume?

Charles，

表示层耦合到业务层，业务层与数据耦合层。到现在为止还挺好。
实际上我通常将表示层耦合到域层

（业务层）并将数据层耦合到域层！


参见Martin Fowler的书企业应用程序架构模式
来自Addison Wesley的

http://www.martinfowler.com/books.html#eaa 。关于Domain Model，

Data Mapper和Separated Interface的章节讨论了如何让数据层

引用域层，而不是让域层引用

数据层。让数据层引用域层，允许

非常容易地替换数据层！另外我发现它提供了更好的分离（减少耦合）...

假设数据层引发一个事件，它将Me（发送者）传递给
一个对象，以及e（MyEventArgs，EventArgs的后代）到
以上的层在我的一个项目中，数据层有自定义事件处理程序

（MyEventArgs，EventArgs的后代） ，而域名层只使用

EventHandler&传递EventArgs.Empty。当我发现域层

需要将更少的信息传递给域层时，那么数据层

对域层做了。

我们可以定义MyEventArgs的业务层版本 - 实际上是
与数据层中的相同 - 并在传递之前将每个元素复制到新的
对象，但这很多打字，现在我们有重复。
我怀疑大多数时候域层在其

事件中所需的信息将与数据层所需的信息不同

事件，所以每个人都有自己的事件处理程序...


希望这有帮助

Jay


" Charles Law" < BL *** @ nowhere.com>在消息中写道

news：eB ************** @ tk2msftngp13.phx.gbl ...采用项目层次结构的解决方案沿n行-tier
系统，使我们有一个数据层，业务层和演示
层。表示层耦合到业务层，业务层耦合到数据层。到目前为止一直很好。

假设数据层引发了一个事件，它将Me（发送者）作为
对象传递给e（MyEventArgs，一个EventArgs的后代）到该层上面
（业务层）。还假设业务层需要将此事件传递到表示层。它将我作为一个对象发送，但是
它发送的是什么？它不能作为MyEventArgs发送它，因为
表示层不知道这些事情。我们可以将表示层连接到数据层，以便它知道MyEventArgs是什么，但肯定是
是禁止的。

我们也可以删除将MyEventArgs定义为另一个项目，其中所有内容都是耦合的，但现在这个常见的项目面临着各种各样的项目的折衷组合的危险。

我们可以定义MyEventArgs的业务层版本 - 实际上是
与数据层中的相同 - 并在传递之前将每个元素复制到新的
对象，但是很多打字，现在我们有重复。

我很想知道其他人在这种情况下做了什么。

Charles

The presentation layer is coupled to the business layer, and the business
layer is coupled to the data layer. So far so good. Actually I normally couple the presentation layer to the domain layer
(business layer) and couple the data layer to the domain layer!

See Martin Fowler''s book "Patterns of Enterprise Application Architecture"
from Addison Wesley
http://www.martinfowler.com/books.html#eaa. The sections on Domain Model,
Data Mapper, and Separated Interface discuss how to have the data layer
reference the domain layer, instead of having the domain layer reference the
data layer. Having the data layer reference the domain layer, allows
replacing the data layer very easily! Also I find it provides better
separation (less coupling)...
Suppose the data layer raises an event, and it passes Me (the sender) as an object, and e (MyEventArgs, a descendent of EventArgs) to the layer above In one of my projects that data layer has custom event handlers
(MyEventArgs, a descendent of EventArgs), while the domain layer simply uses
EventHandler & passes EventArgs.Empty. As I found that the domain layer
needed to convey less information to the domain layer, then the data layer
did to the domain layer.
We could define a business layer version of MyEventArgs - which is actually identical to the one in the data layer - and copy each element to the new
object before passing it on, but that is a lot of typing, and now we have
duplication. I suspect most of the time the info that the domain layer needs in its
events is going to be different then the info needed in the data layer''s
events, so each would have its own event handlers...

Hope this helps
Jay


"Charles Law" <bl***@nowhere.com> wrote in message
news:eB**************@tk2msftngp13.phx.gbl... Take a solution with a project hierarchy along the lines of an n-tier
system, so that we have a data layer, business layer and presentation layer. The presentation layer is coupled to the business layer, and the business
layer is coupled to the data layer. So far so good.

Suppose the data layer raises an event, and it passes Me (the sender) as an object, and e (MyEventArgs, a descendent of EventArgs) to the layer above
(the business layer). Suppose also that the business layer needs to pass
this event on to the presentation layer. It sends Me as an object, but what does it send e as? It can''t send it as MyEventArgs because the presentation layer knows nothing of such things. We could couple the presentation layer
to the data layer, so that it knows what a MyEventArgs is, but surely that
is a no-no.

We could also remove the definition of MyEventArgs to another project to
which everything is coupled, but now this common project is in danger of
being an eclectic mix of stuff that is really specific to individual
projects.

We could define a business layer version of MyEventArgs - which is actually identical to the one in the data layer - and copy each element to the new
object before passing it on, but that is a lot of typing, and now we have
duplication.

I am interested to hear what other people do in this situation.

Charles

这篇关于人们做了什么来避免紧耦合？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！