Как вы организуете свои события на sharepoint?

Question

В последнее время я начинаю много заниматься разработкой sharepoint, и некоторые вещи, которые я сделал, и которые мне не нравятся, - это использовать дизайнер sharepoint напрямую для таких вещей, как макеты страниц, определения списков, главные страницы и т. Д. С моей точки зрения, я думаю, что все организовано, чтобы делать все в Visual Studio. Таким образом, вы можете подключить каждое решение к базе данных управления исходным кодом и проще развернуть / убрать / обновить с помощью сценариев.

Моя идея состоит в том, чтобы создать такое решение против: 1. Один для определения списка и типа контента. 2. Один для веб-частей. 3. Один для брендинга

но, возможно, у этого подхода есть какой-то недостаток, какие другие подходы вы используете?

Answer 1

Реальный ответ будет: это зависит.

Я не думаю, что есть лучший способ организовать решение Visual Studio или пакеты решений SharePoint. В конце концов, вам нужно найти то, что лучше всего подходит для вашей организации, и идти с этим.

Единственное руководство, которое я видел, из документации по SharePoint Online:

Если команда разработчиков разрабатывает решение, которое требует более 10 файлов WSP, команде следует пересмотреть свою архитектуру. Сложно управлять и развертывать такое количество файлов WSP в одном окне развертывания, и решение может быть отклонено из-за сложности управления SharePoint Online.

Большое количество пакетов решений (файлов WSP), которые необходимо отслеживать и управлять ими, представляет собой проблему для развертывания. Чем больше пакетов решений в настройке, тем выше вероятность того, что что-то будет установлено неправильно, тем больше времени потребуется для развертывания решения и тем проще смешивать несовместимые версии пакетов решений. Мы рекомендуем заказчикам тщательно проверять свои планы развертывания и поддерживать количество пакетов решений на минимальном количестве, необходимом для проекта. Помните, что пакет решений может содержать несколько функций, поэтому нет необходимости иметь один пакет решений для каждой функции.

И я бы с этим согласился. Похоже, вы наметили 3 решения Visual Studio и / или пакеты решений SharePoint для того, что на самом деле является 3 функциями в одном пакете решений SharePoint.

Я склонен создавать одно решение Visual Studio для каждого проекта. Для очень большого проекта это одно решение Visual Studio может содержать несколько проектов, каждый из которых представляет пакет решения SharePoint.

Для решений на ферме каждый пакет решений SharePoint будет содержать ряд функций и файлов, которые связаны с точки зрения функциональности или приложения. Если два или более пакета решений SharePoint совместно используют общие компоненты, я помещу эти общие компоненты в отдельный пакет решений.

Решения для песочницы, как правило, намного меньше, чем решения для фермы. В то время как мои решения Farm обычно представляют собой приложение, мои решения Sandbox более сфокусированы на решении одной конкретной проблемы. Поэтому мои решения Sandbox обычно содержат только одну функцию, которая не зависит от других пользовательских функций или решений.

Как я сказал в начале, я не верю, что есть одно жесткое или быстрое правило. Обычно это определяется предпочтениями и стилем конкретной команды разработчиков. Попробуйте сначала несколько разных способов, и в конце концов вы найдете то, что подходит вашей команде лучше всего.