2

我在 Sharepoint 和 Project Server 上开发了一个相当大的项目，设计为多层应用程序。我以编程方式管理某些 Web 部件页面上的 Web 部件。根据用户在其中一个网页中的选择，将适当的网页部件添加到另一个网页部件页面的网页部件集合中。我的问题是我根本不知道在哪里管理 Web 部件，我应该在 BLL 中进行管理，然后让包含业务逻辑的程序集引用 Web 部件所在的 UI 程序集吗？（我需要在将 Web 部件添加到集合时对其进行实例化，因为我不想使用表示 Web 部件 dwp 的硬编码字符串。）

4

4 回答 4

0

您能否将 Web 部件打包为一个功能或一组功能，然后通过 Web 部件管理器类简单地管理功能激活/停用？

任何需要在适当的 Web 部件页面上进行的 Web 部件程序化按摩都可以在功能接收器中处理，因此您的经理不需要非常了解 Web 部件 UI。

HTH, jt

于 2008-12-22T18:03:57.917 回答
0

Web 部件通常最好使用功能/解决方案框架进行管理。您可以将您编写的 webpart 类视为任何其他 web 控件，因此是 ui 层的一部分。我通常将 xml 文件（.webpart 或 .aspx 文件）中的信息保持在最低限度。如果您专门管理它们，则根本不需要使用声明性代码文件。

简短的回答：webpart 是特定于共享点的 ui，应该不了解业务层。

于 2008-12-26T17:04:09.563 回答
0

简短的回答可能是“不，你不应该在 BLL 中这样做”。纯粹主义者可能会争辩说，虽然 BLL 可以正确地确定用户可以做什么或不可以做什么，但最终要由 UI 层来确定要显示的适当 Web 部件。

例如，BLL 可能会确定用户的能力并将其公开为角色、权限或具有域相关含义的其他内容（例如时间表批准者角色、批准时间表权限等）。然后这些可能会被 UI 层映射到一组 Web 部件（例如时间表批准 Web 部件）。通过这种方式，BLL 有效地确定了用户的能力，而 UI 层确定了这些能力的 UI。

于 2008-12-29T04:10:35.643 回答
0

这实际上取决于您为 BLL 和 UI 层使用的模式，以及您希望遵循的严格程度。

如果您正在执行 MVP 模式，那么我建议您Page实现一个具有以下一个（或多个）选项的接口：

  • 要加载的堆栈Presenters被添加到
  • 每个 Web 部件的Load_WebPartName事件，然后应调用该事件以指示需要加载哪些 Web 部件

要成为严格的 MVP，您不应在BLL 项目中引用以下程序集：

  • 系统.Web
  • 微软共享点
  • Microsoft.SharePoint.*

（所有 SharePoint 程序集都在模型或 UI 项目中，BLL 只是连接到适当的飞节）

于 2008-12-29T04:58:03.333 回答