Когда использовать CreateChildControls () против встраивания в ASPX

Question

Я занимаюсь разработкой веб-части для SharePoint 2007 и видел несколько публикаций, в которых рекомендуется делать все создания элементов управления в коде позади . Я перехожу с разработки Java J2EE, поэтому у меня нет истории платформы .Net / ASP / и т. Д.

В других местах показано, как можно сделать то же самое, встраивая определение элемента управления в страницу asp с тегами

Мой вопрос такой:

Какое правило определяет, где внедрять элементы управления? Изменилось ли недавно это правило, может быть ASP против ASP.Net или ASP.Net MVC? Этот совет ограничен разработкой SharePoint?

Answer 1

Я собираюсь отключить тот факт, что вы разрабатываете веб-часть для 2007 года. Веб-части подразумевают, что вы хотите дать пользователям возможность добавлять части на страницы по своему усмотрению. Для реализации веб-части вам потребуется отдельная библиотека DLL, которая либо развертывается в каталоге bin приложения SharePoint IIS, либо в глобальном кэше сборок.

Как правило, в SharePoint у вас нет АСПХ-страницы, чтобы встроить элементы управления и сделать ее воспроизводимой. Страницы ASPX будут создаваться пользователями или функциями, а затем пользователи будут добавлять веб-части на эти страницы. SharePoint, по сути, представляет собой виртуальную файловую систему, и многие страницы ASPX либо находятся в базе данных, либо в корневой папке SharePoint, создавая код за нетривиальной задачей.

Веб-часть должна быть развернута как отдельный DLL-файл. Учитывая способ разработки веб-частей, у вас нет рабочей области для создания пользовательского интерфейса, поэтому вам необходимо создать дерево элементов управления с помощью кода, причем предпочтительным временем в течение жизненного цикла является раздел CreateChildControls (см. Предыдущую ссылку).

Существуют и другие способы обойти это, например Son of SmartPart (http://weblogs.asp.net/jan/archive/2005/11/22/431151.aspx),), который позволяет создать пользовательский элемент управления, а затем загрузить пользовательский элемент управления в дерево элементов управления веб-части. По сути, это подход Microsoft взяли в 2010 году с их функциональностью Visual Web Part.

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

John

Answer 2

вот несколько мыслей.

Создание динамического элемента управления (внутри CreateChildControls ()

• это более динамичное решение
• если схема управления должна быть разной, скажем, для разных пользователей, у вас больше контроля над потоком. Это означает, что вы можете встраивать элементы управления в разные деревья или ветви деревьев, просто делая их видимыми / невидимыми
• может быть более подходящим, если вам нужно сделать экземпляры элементов управления доступными извне сборки

Декларативное определение (ASPX)

• Действительно, стиль ведения дел в стиле MVC.
• Это рекомендуемый способ, если только у вас нет причин не делать этого (возможно, по вышеуказанным причинам)
• НАМНОГО проще поддерживать компоненты пользовательского интерфейса и макет
• вы также можете создавать повторно используемые пользовательские элементы управления декларативным способом, создавая файлы ASCX

Вы также можете смешивать и сопоставлять. Объявляйте некоторые статические элементы и динамически добавляйте другие по мере необходимости, добавляя их в элемент управления Panel во время выполнения.

другой распространенный подход заключается в создании подкласса общих элементов (таких как TextBox или сетка данных) и изменении поведения, вида и / или визуализации этого элемента управления (путем переопределения события Render). Чем вы можете просто использовать свою версию элемента управления внутри ASPX. Это выигрыш / выигрыш, потому что вы получаете максимальный контроль, по-прежнему отделяя макет от бизнес-логики. Я всегда делюсь на подклассы для встраивания общих функций, таких как единообразный вид всех элементов управления, персонализация и т. Д.