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

Question

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

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

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

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

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

无论如何，感觉就像让 UC 有能力/责任来呈现和坚持自己会消除相当多的代码重复。

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

谢谢!

Answer 1

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

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