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

Question

创建与服务层直接通信的“黑匣子”用户控件（执行CRUD操作，验证等），是否认为设计不佳？

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

这种方法有两个因素：

1. 我们的应用程序有许多页面，它们基本上是同一视图的变体（布局略有不同）。

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

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

如果这种方法确实被认为是“icky”，请随意建议一个更具吸引力的替代方案（也许是MVP？）在可预见的未来我会坚持使用WebForms。

谢谢！

Answer 1

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

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

Answer 2

不，这实际上就是如何进行良好的SOA，其中你有“堆栈”水平相对紧密耦合，与其他“堆栈”功能松散耦合。堆栈从UI连接到持久层。想想亚马逊和eBay是如何拥有页面的，每个页面都是一个复合UI，每个UI都独立于其他部分，但每个部分内的层都相互依赖。