问题标签 [decoupling]

这是一个 C# 问题，但实际上可能与语言无关

我继承了一个大型对象模型（100 多种类型），其对象层次结构“拥有”0..n 个其他类型对象，这些对象都共享一个基础（其中存在“相对”严格的类型层次结构）。

我想开始通过继承来解耦这些对象，以组合一个基于 IoC 的系统，以开始实施一些比目前更深入的单元测试。

最好的起点是哪里？

我可以从层次结构的顶部开始，这很简单，但最初的好处最少，并且在我进一步深入链条之前会非常死记硬背，但这需要我在基础对象上实现一些重载函数签名以接受基本接口，直到我得到完全覆盖。

我可以从层次结构的底部开始，这会更棘手，因为那里的类之间有更多的交互，但会“迫使”我们对重构采取更全面的看法。

我也可以从 Base 对象（所有对象都继承自的对象）开始，这将在逻辑点启动进程，但几乎肯定会创建一个不可编译的应用程序，直到我们交换所有对象继承和函数调用.

有什么想法吗？

我正在研究 Juval Lowy 的优秀 Programming WCF Services，我刚刚使用他的 InProcFactory 类和他的 ServiceModelEx 库创建了一个非常简单的进程内组件。

你为什么要这样做而不是在你的项目中只使用常规类？使用他的方法需要引用他的库并创建一个接口。

我能想到几个优点：

• 如果您始终如一地这样做，您将大大减少耦合。
• 一旦您编写了进程内组件，它们就可以在进程外或远程使用而无需更改。

这样做有更多优势吗？

您是否使用进程内 WCF 组件编写代码？

所有类都应该是组件吗？

你能完全脱离整个脱钩吗？

将所有类组件化的缺点是否大于优点？反之亦然？

需要记录一些“高风险”数据操作。在这种情况下，“高风险”操作被定义为写入我们的 ERP 系统。碰巧我们正在将这些事件记录到我们的 SQL Server 数据库中。

伪代码：

消除这种紧密耦合的最佳做法是什么？

我想在我正在构建的应用程序中使用 SubSonic (2.2)，因为我喜欢它的简单性，并且它可以处理我可以预见需要的任何类型的查询。同时，我想让我的应用程序的上层与 Subsonic 类型分离。我想只返回普通的旧 C# 对象，并传入要保存的 POCO。

但这里有个问题：我希望我的 POCO 根据 FK 关系为子集合和父对象延迟加载属性。我想我需要以某种方式将 Subsonic SqlQuery 对象放在我的 POCO 的私有成员中，并在 getter 内部使用它来获取延迟加载的属性。

关于如何使用 SubSonic 专门实现这一点的任何想法？以前有人做过吗？

我确实意识到 SubSonic 的下一个主要版本将立即执行此操作，但这看起来至少需要几个月的时间。

I'm looking for a design pattern that would fit my application design.

My application processes large amounts of data and produces some graphs. Data processing (fetching from files, CPU intensive calculations) and graph operations (drawing, updating) are done in seperate threads.

Graph can be scrolled - in this case new data portions need to be processed. Because there can be several series on a graph, multiple threads can be spawned (two threads per serie, one for dataset update and one for graph update).

I don't want to create multiple progress bars. Instead, I'd like to have single progress bar that inform about global progress. At the moment I can think of MVC and Observer/Observable, but it's a little bit blurry :) Maybe somebody could point me in a right direction, thanks.

他们矛盾吗？

解耦是一件很棒的事情，而且很难实现。然而在大多数应用程序中我们并不真正需要它，所以我可以设计高度耦合的应用程序，它几乎不会改变任何东西，除了明显的副作用，例如“你不能分离组件”，“单元测试是痛苦的屁股”等。

你怎么看？您是否总是尝试解耦并处理开销？

我通过以下方式解耦了此 WPF 应用程序中的事件。

继续解耦的最佳方式是什么？

Shell.xaml：

引导程序.cs：

Shell.xaml.cs：

客户.cs：

上面的代码成功地将视图Shell与模型分离，Customer:IPerson以便我可以交换模型Employee:IPerson等，它以自己的方式处理“已处理”。那是第一个目标。

但现在：

• 如何将Processed方法与专门与 Button 对话分离，以便它也可以与在视图中触发事件的 MenuItem 或 ListView 对话，这样它甚至不必是调用它的元素，例如单元测试类？
• 除了发送者（按钮）之外，我如何更改视图的其他元素，例如，我将如何更改 Shell 中的状态栏？我看到两种方法：
  • 我可以构建一个包含所有视图的容器，并在创建时将容器注入到客户中，然后客户可以查看容器并根据需要操作调用视图（尽管我必须以某种方式匹配发送事件的视图和容器中的视图相同）
  • 我可以在触发事件时以某种方式将整个视图（Window 对象）发送到带有 eventargs的模型，尽管模型需要某种方式来了解（通过接口）在运行时可以操作哪些类型的区域
• 您将如何继续这个应用程序朝着更加解耦的设计方向发展？
• 这实际上是什么模式，例如 MVC、MVP、MVVM？我只看到一个视图（Shell）和一个模型（客户）。
  • 演示者如何适应？
  • ViewModel 如何适应？
  • 控制器如何适应？

我正在使用网络表单、C#、Asp.net。众所周知，在这个模型中，UI和业务逻辑经常混在一起，如何有效的将它们分开呢？

我想使用的示例是：我有一个 GridView 和一个 DataTable（GridView 绑定到 DataTable 并且 DataTable 是从存储过程提供的）。

我希望将 GridView (UI) 和 DataTable (业务逻辑) 解耦。

为 DataTable 编写包装器是否值得？是否有经过验证和测试的实用模式可供您推荐遵循？

如果有经验的人能解释一下，那就太棒了。而且，作为最后一点，我想说 ASP MVC 现在不是一个选项，所以不推荐它。

我的数据库访问层返回一个 DataTable。请注意，我必须使用此数据库层，因为这是公司政策。

我和我的一个朋友就实体框架的使用进行了一些讨论。我有一个项目，我用实体框架作为我的数据层制作了一个 3 层解决方案，并使用数据传输对象从业务层移动到用户界面。我真的很喜欢它提供的松散耦合，因为我可以稍后使用例如 hibernate 更改实体框架。另一方面，我的朋友认为 Entity 框架的目的是对其进行建模，以便可以在用户界面上使用它。您如何将实体框架与您的解决方案结合起来？

我看过几个类似的问题，但没有看到任何直接适用于我的问题，所以如果这是重复的，请原谅我。

为了分离关注点，我试图以某种方式将我的业务对象与逻辑映射到 .dbml 文件中的 LINQ to SQL 数据对象（这对这个 btw 来说是相当新的）。不过看起来我的业务对象需要了解相应的 LINQ2SQL 对象。我阅读了这篇关于尝试通过使用 xml 映射文件来使用 POCO 的文章，这似乎与我想要的相似，只是我没有从表到类的一对一映射，因为有很多我需要为其创建一个额外的表的多对多关系。

我可以很好地将数据访问封装在我的业务逻辑中，这样使用我的业务对象的代码不需要知道任何关于数据库的信息，这很好，但是业务层仍然与数据访问层紧密耦合，这样如果不更改我的业务层对象或为不同的数据提供者创建新的对象（实现相同的接口），我就无法更换 DAL。

我怎样才能解耦这些层？