Лучшие практики SharePoint с решениями

Question

Мне было интересно, смогу ли я подумать о том, каковы лучшие практики для веб-частей sharepoint и структуры Visual Studio.Под этим я подразумеваю, что у меня есть несколько проектов приложений формы sharepoint, у всех есть несколько вкладок или страниц в рамках своего проекта (страница администратора, страница просмотра записей и т. Д.), И все они находятся в одном грандиозном проекте компании «интранет».Я вижу множество учебных пособий и других сайтов, которые, кажется, превращают все свои веб-части в отдельные решения, а что нет.У меня есть три вопроса:

1.) Должна ли каждая «часть» проекта формы, даже если это другая страница, находиться в разных веб-частях ИЛИ того же проекта?Я думаю, что последнее, потому что если бы это было в другом проекте, было бы трудно получить контроль во время выполнения.

2.) Должны ли другие формы того же основного проекта интрасети, но в их собственной Visual Studioпроекты будут в одном решении?или разные.

3.) Библиотеки классов ... Они сделаны так же, как WPF или ASP.net?

Answer 1

Ну, это действительно зависит от ваших требований. Большую часть времени я использую WebPart просто как обертку для динамической загрузки моих UserControls (которые находятся в другом проекте, но в том же решении). Если вам нужно что-то более «статичное», я бы порекомендовал использовать страницу приложения вместо WebPart.

Я попробую объяснить это на примере:

Допустим, вы хотите создать решение, которое поможет вашим менеджерам проектов выполнять свою работу (хаха :-). Вы бы назвали это приложение чем-то вроде «PM App». Он состоит из 3 частей: системы отслеживания проблем, системы отслеживания времени и приложения для создания отчетов.

Первым шагом, очевидно, является создание пустого решения под названием «PM App». Поскольку у всех трех частей решения есть что-то общее, например, компонент логгера или DataAccessLayer, вы создадите новый проект с именем «Common».

Тогда это действительно зависит от дизайна вашего решения. Допустим, мы идем для решения WebPart / UserControl. Вы создаете новый проект с именем «SP PM», который является проектом SharePoint (на самом деле, я еще не нашел подходящего имени для этого проекта). Затем вы создаете WebPart для каждой части вашего решения (IssueTrackerWebPart и т. Д ...). Теперь, если у вас есть только 1 UserControl на WebPart, легко peasy. WebPart в основном действует как оболочка для ваших пользовательских элементов управления.

Если вы (хотите) иметь несколько пользовательских элементов управления, это становится довольно сложно. Я всегда заканчиваю тем, что создаю новый проект ASP.NET WebApplication с именем «UserControls» и добавляю туда свои UserControls. Проблема с этим способом заключается в обращении к элементам управления UserControls в вашем проекте "SP PM". Ссылка на DLL не проблема, ссылка на файлы .ascx, с другой стороны, есть.

Что я делаю, так это скопирую файл (ы) .ascx из моего проекта «UserControls» в мой проект «SP PM» с помощью посткомпилированного скрипта. Я знаю, что это определенно не лучшее решение, однако я говорил со многими другими разработчиками об этой проблеме, но до сих пор никто не нашел лучшего решения.

Это действительно сложная проблема в контексте SharePoint (как и в любом другом на самом деле), и, насколько я знаю, не существует каких-либо рекомендаций. Лучше всего сидеть вместе с коллегами-разработчиками и спрашивать их, как они будут создавать структуру решения / проекта, а затем находить хороший средний путь.

tl; dr нет "универсального" способа - действительно зависит от ваших требований.

Я быстро описал решение так, как мне кажется:

Надеюсь, это имеет какой-то смысл для вас, и не стесняйтесь спрашивать, есть ли у вас какие-либо дополнительные вопросы. Также я хотел бы услышать некоторые мнения о том, как другие люди подходят к этим вопросам: -)