ASP.NET ascx против aspx - Вы повторно используете пользовательские элементы управления? - PullRequest
11 голосов
/ 12 ноября 2008

Наша команда разрабатывает довольно большой веб-проект ASP.NET, который изначально был запущен в ASP.NET 1.0 и несколько раз переносился на все новые версии .NET.

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

Для многоразовых, небольших и специализированных элементов управления мы используем серверные элементы управления (унаследованные от класса WebControl), которые прекрасно работают.

Итак, мой вопрос: начиная новый проект, можно ли избавиться от ascx и реализовать все на самих страницах (aspx) ? Может быть, кроме случаев, когда вы делаете много динамической загрузки (мы не делаем) пользовательских элементов управления? Каков ваш опыт и что бы вы посоветовали?

Ответы [ 4 ]

16 голосов
/ 12 ноября 2008

У нас есть проекты, в которых широко используются элементы управления ASCX, а другие - нет. По моему опыту, вы должны принимать решение в каждом конкретном случае.

Две мои любимые причины использования элементов управления ASCX:

  1. Вы реализуете часть функциональности пользовательского интерфейса, которая будет появляться на разных страницах (или несколько раз на одной странице).
  2. Вы хотите инкапсулировать некоторые сложные функции, чтобы они отличались от остальной части страницы, что делает ваш код более легким для чтения и более легким в обслуживании.

Элементы управления ASCX могут быть полезны, но вам действительно нужно убедиться, что вы используете их только тогда, когда есть веская причина - иначе - как вы говорите, вы можете добавлять ненужную сложность в свою кодовую базу.

6 голосов
/ 12 ноября 2008

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

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

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

2 голосов
/ 12 ноября 2008

Это просто сводится к типу веб-приложения, которое разрабатывается. На работе одно из наших приложений очень настраиваемо, поэтому работает на одной странице (default.aspx) и загружает элементы управления в зависимости от того, как оно настроено для вошедшего в систему пользователя.

Однако, с другой стороны, если вы пишете веб-сайт, к которому нужно обращаться через SEO, и который должен быть легким для навигации, тогда реализация каждого представления на странице aspx является хорошим способом. Облегчает и упрощает доступ к каждой странице во время разработки, так как вы можете получить к ней прямой доступ (при условии отсутствия прав доступа или логики), настроив ее в качестве начальной страницы в VS.

Еще одна опция, которую можно добавить в микс - это использование ASP.net MVC; взаимозависимые представления с многократно используемыми пользовательскими элементами управления также добавлены в смесь: -)

2 голосов
/ 12 ноября 2008

Я бы по-прежнему использовал пользовательский контроль, и в основном потому, что таким способом вы можете значительно легче отделить контент от дизайна, что в конечном итоге очень поможет, когда вы меняете дизайн приложения.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...