Sharepoint Web 部件管理
我有一个在 Sharepoint 和 Project Server 上开发的相当大的项目，设计为多层应用程序。 我以编程方式管理某些 Web 部件页面上的 Web 部件。 根据用户在其中一个网页中的选择，将适当的Web部件添加到另一Web部件页面的Web部件集合中。 我的问题是，我根本不知道在哪里管理 Web 部件，我应该在 BLL 中进行管理，然后让包含业务逻辑的程序集引用 Web 部件所在的 UI 程序集吗？ （将 Web 部件添加到集合时，我需要实例化它们，因为我不想使用代表 Web 部件 dwp 的硬编码字符串。）
I have a rather large project developed on Sharepoint and Project Server, designed as a multi-tier application. I programmatically manage web parts on certain web part pages. According to the choices of the user in one of the web pages, appropriate web parts are added to the web part collection of another web part page. My problem is that I simply do no know where to manage the web parts, should I do it in the BLL and then have the assembly containing the business logic reference the UI assembly where the web parts are? (I need to instantiate the web parts when adding them to the collection, since I do not want to use hard coded strings representing the web part dwp.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这实际上取决于您的 BLL 和 UI 层使用什么模式，以及您想要遵循它的严格程度。
如果您正在使用 MVP 模式，那么我建议您让
Page实现一个接口，该接口具有以下一个（或多个）选项：Presenters的堆栈要加载的 code> 被添加到WebPartName事件中，然后应调用该事件来指示需要加载哪些 Web 部件要成为严格的 MVP，您应该 < em>不在 BLL 项目中引用以下程序集：
（所有 SharePoint 程序集都位于模型或 UI 项目中，BLL 只是连接到适当的飞节）
It really depends on what pattern you're using for your BLL and UI layers, and how strictly you want to follow it.
If you're doing a MVP pattern then I'd suggest that you have the
Pageimplementing an interface which has one (or more) of the following options:Presentersto load are added toWebPartNameevent for each web part which then should be called to indicate which webpart(s) need loadingTo be strictly MVP you should not reference the following assemblies in your BLL project:
(All SharePoint assemblies would be in either the Model or UI projects, the BLL is just connecting to the appropriate hocks)
您是否可以将 Web 部件打包为一个功能或一组功能，然后通过 Web 部件管理器类简单地管理功能激活/停用？
需要在适当的 Web 部件页面上进行的任何 Web 部件编程操作都可以在功能接收器中处理，因此您的经理不需要太了解 Web 部件 UI。
哈特哈，
杰特
Can you package the web parts as a feature or set of features and then simply manage the feature(s) activation/deactivation through the web part manager class?
Any programmatic massaging of the web part that needs to happen on the appropriate web part page can be handled in the feature receiver, so your manager doesn't need to be so aware of the web part UI.
HTH,
jt
通常，使用功能/解决方案框架可以最好地管理 Web 部件。 您可以将编写的 Webpart 类视为任何其他 Web 控件，从而成为 ui 层的一部分。 我通常将 xml 文件（.webpart 或 .aspx 文件）中的信息保持在最低限度。 如果您专门管理它们，则根本不需要使用声明性代码文件。
简短的回答：webpart 是特定于共享点的 ui，并且不应该了解业务层。
Web parts are generally best managed using the feature/solution framework. You may treat the webpart classes you write as any other web control, and thus a part of the ui layer. I generally keep the information in the xml files (the .webpart or .aspx files) to a minimum. If you are managing them exclusively, you don't really need to use declarative code files at all.
The short answer: webparts are sharepoint specific ui, and should have no knowledge of the business layer.
简短的回答可能是“不，您不应该在 BLL 中执行此操作”。 纯粹主义者可能会争辩说，虽然 BLL 可以正确地确定用户可以做什么或不能做什么，但要由 UI 层来确定要显示的适当 Web 部件。
例如，BLL 可能确定用户的能力并将其公开为角色、权限或具有域相关含义的其他内容（例如，时间表批准者角色、批准时间表权限等）。 然后，这些可能会被 UI 层映射到一组 Web 部件（例如时间表批准 Web 部件）。 通过这种方式，BLL 有效地确定了用户的功能，而 UI 层则确定了这些功能的 UI。
The short answer is probably "no, you should not do this in the BLL." A purist might argue that while the BLL may rightfully determine what a user can or can't do, it is up to the UI tier to determine the appropriate web parts to be displayed as a result.
For example, the BLL might determine a user's capabilities and expose them as roles, or permissions or something else with domain-related meaning (e.g. timesheet approver role, approve timesheet permission, etc.). These might then be mapped to a set of web parts by the UI tier (e.g. timesheet approval web part). In this way, the BLL effectively determines the users capabilities and the UI tier determines the UI for those capabilities.