Вопрос

Вы используете архитектуру корпоративных слоев при создании решений SharePoint? Можете ли вы дать мне проект сайта CodePlex.com/other, в качестве примера, где я могу найти многоуровневый дизайн? (Интерфейс/bl/dal)

Это было полезно?

Решение

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

Для хорошего чтения на многоуровневой архитектуре в ASP.NET ознакомьтесь с этой статьей здесь. Анкет Это asp.net и nhibernate, но принципы одинаковы. В .net также есть многоуровневая образец архитектуры. здесь на Codeplex. Опять же, не специфичный для SharePoint, но принципы одинаковы.

Сохраняйте понадопление SharePoint тонким и сопротивляйтесь искушению начать чтение/запись в списках в вашем коде веб -части. Обратитесь к нему как к базе данных (потому что это так!)

Другие советы

Согласен с BIL.

Веб -части, веб -элементы управления, страницы приложений и т. Д. Должен быть только слой пользовательского интерфейса, который вызывает в слое, который является агностиком исходного контекста вызова; Контекст вызова может быть приемником событий, приложением консоли, заданием таймера, рабочим процессом и т. Д. Принять Spwebs, Splists, Splisitems и т. Д. В качестве параметров метода и параметров конструктора. В веб -контексте вы можете передать их из spcontext.current, но в приложении консоли вы бы построили бы их самостоятельно.

Чтобы улучшить простоту отладки (просто нажмите F5) и сократить цикл обратной связи разработчика, я часто начинаю записывать простое приложение для консоли, которое вызывает в слое, которое будет содержать логику ядра, передавая в SPWEB, которое я построил в приложении консоли. После того, как основная логика будет закончена, я пишу тонкий веб -контроль или веб -часть, чтобы заменить приложение консоли, читаю SPWEB из контекста вместо его построения, настраивая обработчики событий и т. Д.

Бил и Джаап (или кому -либо еще),

Мне интересно, какой тип объектов/интерфейсов вы проходите между слоями? Вы откидываете Splistitem или откидываете какой -то интерфейс, который представляет Splistitem?

SharePoint - это странное зверь, потому что пользователь фактически имеет возможность изменить структуру данных через веб -интерфейс (он может добавить/удалить/изменить столбцы в списке). Если вы передаете объект/интерфейс, каждый раз, когда список изменяется пользователем, код должен быть перекомпилирован (и развернут) для размещения нового столбца (свойства). Если вы передаете SPLISTITEM, вы фактически разбиваете уровень, предоставив прямой доступ к источнику данных (SharePoint).

Лицензировано под: CC-BY-SA с атрибуция
Не связан с sharepoint.stackexchange
scroll top