从长远来看，传递整个对象还是传递一系列参数更易于维护？
我通过在页面的构造函数中包含对对象的引用作为参数来将数据传递到 C# 中的页面。我仅使用页面中对象的一部分成员。对此类页面的调用如下所示：
new PageName(DataObject);
其中 DataObject 设置为新页面的 DataContext：
this.DataContext = DataObject;
从中我可以执行需要对 DataObject 执行的所有数据操作。此设置的一个关键功能是对 DataContext 所做的更改会影响传递的 DataObject；这是有意且可取的。
这相当简单，目前效果很好。我担心的一个问题是 PageName 必须知道将 DataContext 转换为正确的对象类型，并且必须知道对象属性的名称，从而创建显着的耦合。这通常是可接受的耦合级别，还是值得努力传递 ref 参数来减少 PageName 和 DataObject 之间的耦合程度？
编辑：平均而言，如果我传递参数，我通常需要向每个页面传递 4-5 个参数。并非每个页面都需要传递给它的相同参数。
I am passing data to Pages in C# by including a reference to an object as a parameter in the page's constructor. I'm only using a portion of the members of the object in the page. A call to such a page looks like so:
new PageName(DataObject);
Where the DataObject set to be the DataContext of the new Page:
this.DataContext = DataObject;
From which I can perform all data operations I need to do on DataObject. One key feature with this setup is that changes made to the DataContext affect the passed DataObject; this is intended and desirable.
This is fairly simple and works well for now. One concern i have is that PageName must know to cast DataContext to the correct object type, and must know the names of object properties, creating significant coupling. Is this generally an acceptable level of coupling, or would it be worth the effort to pass ref parameters to reduce the magnitude of coupling between PageName and DataObject?
Edit: On average, if I were passing parameters, I would usually need to pass 4-5 parameters to each page. Not every page needs the same parameters passed to it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有一个名为引入参数对象的重构。
它存在的事实表明使用一个对象而不是多个参数是更易于维护的选项。
这是框架中在多个地方使用的模式 - 请参阅
Process和ProcessStartInfo- 当一个对象可以通过多种方式配置时，提供一个配置对象（是的，这是紧密的）耦合到对象）是一项设计决策。如果配置对象仅与它配置的对象一起使用，那么我确实认为这种耦合没有问题。
There is a refactoring called introduce parameter object.
The fact that it exists points to having an object instead of multiple parameters as being the more maintainable option.
This is a pattern used in the framework in multiple places - see
ProcessandProcessStartInfo- when an object can be configured multiple ways, supplying a configuration object (yes, that is tightly coupled to the object) is one design decision.If the configuration object is only to be used with the object it configures, I don't really see a problem with this coupling.
来自受人尊敬的《Code Complete》（史蒂夫·麦康奈尔），第 1 章。 7：
并且来自第 1 章。 13：
From the venerable Code Complete (Steve McConnell), Ch. 7:
And from Ch. 13:
如果您的页面预计不会发生太大变化，那么它将消耗的数据将相对固定，在这种情况下，传递多个特定值会带来许多好处：
但是，这可能存在以下缺点：
如果参数数量很少（可能是 1-4 个）并且您非常确定您的数据要求不会改变，我会坚持使用单独的参数。如果所需的参数数量超过 5 个或者您认为数据需求会发生变化，我会传递一个对象。
还有第三种选择，即通过将 DataContext 传递给中间对象类型来构造中间对象类型，然后将其传递给您的页面。这意味着您具有解耦（可能在调用站点和被调用的构造函数处，因为只有中间对象需要直接耦合到 DataContext）、封装/保护（仅传递/使用/更改 DataContext 中所需的数据成员） ，单参数（高效）调用，并且易于维护（要复制的参数知识位于一个位置，即中间对象，而不是位于每个调用站点）。这样做的缺点是您必须将数据复制到中间对象中并从中复制出来，这可能会影响性能。这种方法可能有用，但在使用之前请仔细考虑具体情况。
If your page is not expected to change much, then the data it will consume will be relatively fixed, in which case you get a number of benefits of passing several specific values:
However, this has the following possible cons:
I would stick with separate parameters if the number of parameters is low (maybe 1-4) and you are pretty sure your data requirements won't change. If the number of parameters required is 5+ or you think the data requirements will change, I'd pass a single object.
There is a third option, which is to construct an intermediate object type by passing it the DataContext, and then pass this to your page. This means you have decoupling (potentially at both the call site and the called constructor because only the intermediate object needs to be directly coupled to the DataContext), encapsulation/protection (only the required data members from DataContext will be passed/used/changed), a single-parameter (efficient) call, and easy maintenance (knowledge of the parameters to copy are in one place, the intermediate object, rather than at every call site). The con of this is that you have to copy the data into and back out of the intermediate object which could affect performance. This approach may be useful, but consider the exact circumstances carefully before using it.