SharePoint 2010 - лучшие практики: как обрабатывать сборки [Обсуждение]

Question

Есть обсуждение, которое происходит для серверных лет при программировании для SharePoint.

В Visual Studio вы можете добавить решение SharePoint, которое будет преобразовано в файл .wsp для развертывания. Этот файл .wsp будет содержать все необходимые файлы сборки.

Как вы, ребята, вручите файлы Codebehind для: приемника событий, ресивера функций, PAGE ASPX?

Вы размещаете этот файл .cs внутри вашей папки SharePoint? (Таким образом, вам нужно будет развернуть .dll от вашего проекта SharePoint Aswell)

Или вы перемещаете всю логику кода на один (или более) разных проектов (S) (библиотеки классов)?

Что вы делаете, например, во втором примере:

.
• Щелкните правой кнопкой мыши, добавьте новый элемент, приемник событий
• Переместите файл .cs к другому проекту
• Измените информацию об сборке внутри элементов .xml Файл

  В первом примере мы не перемещаем эти файлы, просто держите их как vs2010 добавляют их.

  Я не говорю, что я предпочитаю, я просто хочу получить много ввода. Не просто скажи "вариант 2 плохой". Я действительно хотел бы знать, почему и почему нет!

  Спасибо

  Редактировать:

  Мой вопрос здесь не имеет ничего общего с расширениями и т. Д.

  Я говорю о том, чтобы убедиться, что ваш раствор SharePoint не содержит ни одного файла .cs. Таким образом, не должно быть собранием в GAC для этого решения.

  Пример: у меня есть Customer.sps.intranet.solution (= решение для генерации WSP, поэтому пустой элемент проекта SharePoint).

  Если я просто добавляю функцию и приемник функциональности, файл .cs генерируется и (после развертывания) файл customer.sps.intranet.solution.dll помещен в кэш глобального монтажа.

  Это то, что некоторые люди не хотят иметь !!! (Я не понимаю, почему, вот почему я прошу мнения).

  Чтобы решить это, они создают проект внутри этого решения с именем: «Customer.SPS.Intranet.Logic», это решение будет содержать все файлы файлов приемника функций.

  Это означает, что мы должны редактировать файл Template.xml, чтобы использовать класс приемника, расположенный в проекте «Логика». Таким образом, мы сохраняем «Customer.sps.intranet.solution», и мы будем использовать только его для упаковки. Таким образом, не будет никакой ассамблеи, развернутой для GAC по имени «Customer.SPS.Intranet.solution.dll» ... вместо клиенту .sps.intranet.logic.dll в сборе развернута в GAC.

Answer 1

AAAH, Вечный вопрос решений и DLL. :-) Зачем расстаться, почему бы и нет, а когда? Я не работаю в банкомате, я в отпуске, но, как вы просили меня взглянуть, я просто сделаю сумму несколько забрал, и мой взять на него. Так что мой ответ основан на личном опыте и просмотре. (извините stackexhange)

x Не разделение «кода позади» и UI приводит к упорству кода для обслуживания. Что-то, что я видел на разных проектах, заключается в том, что неопытные разработчики не хорошо справляются с «кодом позади» (C # классы рядом с XML / ASPX), они имеют тенденцию писать больше логики в код, поскольку они имеют прямой доступ к интерфейсу. На одном конкретном проекте я видел «новую» страницу 1500 строк (которая уже огромна), а страница «Редактирование» была в основном копировальной и пастой новой страницы. Уверен, что это «плохое программирование», он не присущ в насущный код позади рядом с артефактами. Но вредные привычки трудно измениться, и эта модель работы может помочь сделать все хуже. В этом случае создание класса CS сначала в качестве контроля и имея какой-то унаследованный класс для класса редактирования, было бы более легко поддерживать. После создания вы можете сделать ваши страницы ASPS наследуют из этих классов.

x Не разделение "кода позади" и Ui приводит к классам со слишком много логики. Другое в этом проекте - это то, что как новая страница, поскольку страница редактирования имела прямые подключения к внешним базам данных SQL. Они использовали прямые соединения SQL, которые создали накладные расходы в код и обслуживание. Слоистый подход очень помог бы.

x Слоистое приложение требует отдельных сборки. Ну, наслоение хорошее! Вам нужна отдельная сборка для него? Не обязательно. Вы можете группировать вашу логику, данные ACCES ACCES ITC в отдельных папках / пространствах имен в вашей сборке. Это также слои. «Но почему я должен разделить их?» Это имеет тенденцию быть хорошей практикой. Почему? Ну, вы избегаете случайного использования более глубокой логики (например, соединения SQL), так как эта логика ссылается только в слое DA. Другое преимущество заключается в том, что потенциально проще заменить верхние слои на другой слой. Скажите другой пользовательский интерфейс или мобильный интерфейс. Вы можете протолкнуть его еще больше и сделать более низкие слои более универсальными, поэтому вы можете использовать их позже. Вот как можно создавать NHIBERNATE и EF Framework.

x "Это приятно, но это просто развитие asp.net". Правильно, но одни и те же принципы и идеи могут использоваться при разработке артефактов SharePoint, таких как приемники. Почему бы не работать на основе родовых приемников, которые могут быть параметризованы с свойствами функций или папкими свойствами? Повторное использование логики в основном приводит к более стабильным решениям.

x разделение поощряет (единица) тестирования. Как только вы начнете разделяться и создавать более общий класс и т. Д., Это больше больше не длится использовать интерфейсы и модели. Это означает, что тестирование подразделения будет более легко реализовать (хотя мы должны на самом деле использовать TDD), так как мы можем легче издеваться. Посмотрите на Framework MVC и как вещи там красиво разделены. Это работает также для SharePoint.

Так, чтобы обобщить мою 2C (и изменение ;-)), вы можете использовать код позади непосредственно прилив на ваш артефакт, но я не предпочитаю. Я скорее пойду на повторное использование, общий и тестичный код, чем иметь автоматические подходящие приемники и код для артефактов (хотя вам не нужно менять шаблон функции XML в ручном случае, так как вы просто добавляете приемник функциональности в свойствах) и Свободно найти (я использую мгновенное время в VS2010), но в конце концов, это все о том, что вы и ваш проект предпочитаете. : -)

Answer 2

На самом деле, лично, никогда не сталкивался с решением, где файлы из решения SharePoint были перемещены вне проекта, за исключением, возможно, для ситуаций, когда вы определили многоразовые части: E.g. Методы расширения, код обработчика базового события. Существует также причина не выдвигать его, например Обычно VS 2010 использует GUID, с которыми классы оформляются для внутренней обработки, он соединяет обработчик, поэтому он может правильно создать зависимости. Кроме того, все двоичные файлы, в любом случае, в любом случае, в любом случае, поэтому код - рядом (не более кодовый в SP2010) уже встроен. Помимо регистрации SafeControls (веб-частей, пользовательских элементов управления и т. Д.). вручную - плохо для производительности.

Это первоначальные отражения, могут вернуться с некоторыми еще, но нижнее правило: вы не используете эти кусочки - тогда лучше оставить их, где VS предлагает. Скорее планируйте перед собой какую функциональность вы развертываете, какие зависимости у вас есть, характеристики природы, порядок активации и т. Д.

Надеюсь, это поможет, C: \ Marius