Веб-приложение ASP.NET - 5000 строк кода на 1 странице - приемлемо?

Question

Я создаю веб-приложение на основе ASP .NET 2.0 (C #), которое в первую очередь предназначено для внутрисетевого использования, то есть для использования внутри локальной сети организации.

Что касается интерфейса пользователя, мне нужно выбрать 2 подхода.

1. Создайте 1-страничное веб-приложение с большим количеством элементов управления ASP .NET AJAX 1.0 (модальные всплывающие окна) для отображения категорированного контента, который в противном случае был бы помещен на отдельную страницу .aspx.

2. Используйте традиционный подход и создайте несколько страниц.

Пользовательский интерфейс на 1 страницу выглядит и чувствует себя очень круто. Однако у меня есть сомнения относительно его масштабируемости.

Согласился, что приложение предназначено для использования по локальной сети, но, поскольку это веб-приложение, оно может потенциально использоваться из Интернета, если клиент захочет.

Благодаря пользовательскому интерфейсу на 1 страницу уже имеется около 2600 строк кода на одной странице .aspx и еще 1600 строк кода в коде позади (.aspx.cs)

Это будет увеличиваться - до максимум - 10 000 строк кода (10 000 в .aspx и 10 000 в .aspx.cs). Поэтому мне нужно знать - сколько это слишком много для страницы на базе ASP .NET - хорошо ли 2600 + 1600 строк кода для интранета и доступа в Интернет? Как насчет 10000 строк кода? Что такое горлышко бутылки? Этот одностраничный подход приемлем или мне нужно вернуться к традиционному многостраничному подходу?

Answer 1

Прежде чем я скажу то, что намереваюсь сказать, я хотел бы заявить, что я не думаю, что это хорошая идея. Любой класс (ASP.NET) или нет, который имеет длину 5 или 10 тысяч строк, нуждается в рефакторинге. Здесь много комментариев, в которых утверждается, что время загрузки будет слишком долгим. Тот факт, что у вас есть файл .aspx, в который встроено 5 тыс. Строк кода или 5 тыс. В файле с выделенным кодом (или обоими), не означает, что время загрузки будет значительным только из-за этого. Эти строки кода компилируются и выполняются на сервере, они не передаются клиенту. Таким образом, нет прямой зависимости между количеством строк кода и размером загружаемого файла.

Сайед Ибрагим Хашими

Моя книга: Внутри Microsoft Build Engine: Использование MSBuild и Team Foundation Build

Answer 2

Независимо от увеличения времени загрузки такой невероятно раздутой отдельной страницы, это было бы просто кошмаром. Я согласен с Брэдом, одностраничный подход не верен. И я не могу придумать способа оправдать 10 000+ строк в одном коде позади.

Answer 3

если вам нужно иметь все функциональные возможности на одной веб-странице, я предлагаю переместить код в отдельные элементы управления ascx и объединить все ascx в одну aspx

Answer 4

Не в порядке, разбить вещи на разные файлы по функциональности или разделу.

Здесь полезны элементы управления. Если на этой странице есть бизнес-логика, поместите ее в BLL. То же самое с DAL.

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

Answer 5

Вы всегда должны думать о людях, которые попытаются понять ваш код, чтобы изменить ваше приложение после вас. Во всяком случае, я думаю, что одна страница - это определенно не приемлемо. Не существует "традиционного многостраничного подхода". Если ваше приложение содержит различные действия, оно должно быть «многостраничным»

Answer 6

На первый взгляд, это звучит как ужасное решение для меня (держу пари, ваш DAO встроен в представление), но это невозможно сказать, не просмотрев реальный код.

И, по крайней мере, у вас был смысл искать другое мнение и другие варианты ... Ваши опасения в отношении масштабируемости действительны.

Тщательно подумайте о наложении слоя на ваше приложение с одобрением ... Как ваше монолитное решение может быть преобразовано в "должным образом наслоенное" решение с учетом поддержки представления WML?

Answer 7

У меня есть несколько страниц с 2K строк на .aspx и 10000+ в файле с кодом. У меня есть много функций, которые не используются где-либо еще на сайте и полагаются на некоторую информацию о состоянии просмотра. По-моему, и в этой ситуации я думаю, что это повышение производительности, а не обращение к серверу за поиском функций на другой странице и т. Д. Иногда я думаю, что вам просто нужно делать то, что нужно, и это то, что есть. Просто постарайтесь сделать ваш код максимально эффективным.

Answer 8

Ваши номера на ПУТИ ОТ "ОК". На самом деле они пагубны, если честно с тобой ...

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

Answer 9

10k кода на одной странице это слишком много (это может работать нормально), но вы можете поддерживать этот код ?? я не уверен, что кто-то может:)

Answer 10

Я удивлен, что никто не упомянул ViewState. Я думаю, что если вы минимизируете размер ViewState (используя элементы управления ascx и загружаете их динамически), то хорошо разработанное «одностраничное решение» подойдет.