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

Question

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

通过“黑匣子”，我的意思是它们独立于托管的页面检索/保留数据(使用 IoC 注入(inject)服务)。每个 UC 都可以拖放到一个页面上，然后它就会工作。请注意，这些 UC 中没有嵌入任何业务逻辑(全部在域层中)。

这种方法是由两个因素驱动的:

1. 我们的应用程序有许多页面本质上是同一 View 的变体(布局略有不同)。

2. 此外，我们的 UI 设计师很喜欢 允许页面的离散部分 可以打开进行编辑。点击 here一次糟糕的尝试 说明这个概念。

   无论如何，感觉赋予 UC 渲染和持久化自身的能力/责任将消除相当多的代码重复。

如果这种方法确实被认为“令人讨厌”，请随意建议一种更有吸引力的替代方法(也许是 MVP？)在可预见的 future 我将继续使用 WebForms。

谢谢!

Answer 1

假设您以这种方式正确实现了每个控件的 MVP 模式，这在我看来是完全可以接受的。

就我个人而言，我解决此类问题的方法是允许我的 MVP 模式具有可以访问许多 View 的混合 View 呈现器(例如 IListView、IEditView)，但是这会如果它们确实是用户控件，那么执行起来会遇到更多问题，因为它们有一半存在于页面之外。如果它们是带有自己标签的用户控件，您可以按照您在问题中询问的方式实现它，或者您需要公开所有可能的事件以在页面上实现代码。