直接与服务层通信的ASP.NET用户控件？

创建直接与服务层通信的“黑盒”用户控件（用于执行CRUD操作、验证等）是否被认为是糟糕的设计

所谓“黑盒”，我的意思是，它们独立于承载它们的页面（使用IoC注入的服务）检索/持久化数据。每个UC都可以放到一个页面上，它只会工作。请注意，这些UCs中没有嵌入任何业务逻辑（都在域层中）

这种方法由两个因素驱动：

我们的应用程序有许多页面，这些页面本质上是同一视图上的变体（布局略有不同）

此外，我们的用户界面设计师很喜欢 允许页面的离散部分 打开进行编辑。点击 因为一次拙劣的尝试 说明这一概念

无论如何，让UCs能够/负责自己呈现和持久化将消除相当多的代码重复

如果这种方法确实被认为是“讨厌的”，请随意推荐一种更具吸引力的替代方法（也许是MVP？），在可预见的未来，我会一直使用WebForms

---

谢谢

假设您以这种方式为每个控件正确实现MVP模式，这是完全可以接受的

---

就我个人而言，我解决这类问题的方法是允许我的MVP模式具有混合视图演示器，可以访问许多视图（想想

IListView

，

IEditView

），但是如果它们是真正的用户控件，那么这将是一个更大的问题，因为它们从一开始就存在于页面之外。如果它们是带有自己标签的用户控件，那么您可以按照您在问题中要求的方式来实现它，或者您需要公开所有可能的事件以在页面上实现代码。

不，这实际上是做好SOA的方法，在SOA中，您有相对紧密的水平耦合的“堆栈”，与其他功能“堆栈”松散耦合。堆栈从UI一直绑定到持久层。想想亚马逊和EBay是如何拥有页面的，每个页面都是一个复合UI，UI的每一部分都独立于其他部分，但在每一部分中，各层都相互依赖。

不幸的是，我没有使用MVP实现这些用户控件，尽管我一直在考虑重新编写它们。我刚刚读了你关于“创建通用模型视图演示者框架”的博文（顺便说一句，很好），我想知道我是否可以将相同的基本MVP模式应用于用户控件。注释？是的，您应该能够以类似的方式实现它们。我将有一篇关于MVP模式的新博文，以及如何利用CurrentHandler动态解析视图，将视图与ASP.NET中的presenter解耦（我不确定是否可以在用户控件中执行此操作，您必须对其进行测试）但是你应该检查一下这显示了一种方法，你可以欺骗编译器让你正确地将它转换到你的视图中，这应该也适用于用户控件。我们可以使视图松散耦合，而不是像演示者使用setter将视图连接到演示者的标准实现那样强耦合。