Код позади в ASP.NET MVC
Размер структуры больше, чем сумма ее частей из-за того, что называется упаковкой. У конкретного процессора есть предпочтительный размер данных, с которым он работает. Большинство современных процессоров предпочитают размер, если 32 бит (4 байта). Доступ к памяти, когда данные находятся на этом типе границы, более эффективен, чем те, которые охватывают эту границу размера.
Например. Рассмотрим простую структуру:
struct myStruct
{
int a;
char b;
int c;
} data;
Если машина является 32-разрядной машиной, а данные выровнены по 32-битной границе, мы видим немедленную проблему (при отсутствии выравнивания структуры). В этом примере предположим, что данные структуры начинаются с адреса 1024 (0x400 - обратите внимание, что младшие 2 бита равны нулю, поэтому данные выравниваются с 32-разрядной границей). Доступ к data.a будет работать нормально, потому что он начинается на границе - 0x400. Доступ к data.b также будет работать нормально, поскольку он находится по адресу 0x404 - еще одна 32-разрядная граница. Но неуравновешенная структура поставит data.c по адресу 0x405. 4 байта данных.c находятся в 0x405, 0x406, 0x407, 0x408. На 32-битной машине система считывала data.c в течение одного цикла памяти, но получала бы только 3 из 4 байтов (четвертый байт находится на следующей границе). Таким образом, системе потребуется второй доступ к памяти для получения 4-го байта,
Теперь, если вместо того, чтобы поместить data.c по адресу 0x405, компилятор заполнил структуру на 3 байта и поместил данные. c по адресу 0x408, тогда системе потребуется всего 1 цикл, чтобы прочитать данные, сократив время доступа к этому элементу данных на 50%. Заполняет эффективность памяти для эффективности обработки. Учитывая, что компьютеры могут иметь огромные объемы памяти (много гигабайт), компиляторы считают, что своп (скорость над размером) является разумным.
К сожалению, эта проблема становится убийцей при попытке отправить структуры по сети или даже записать двоичные данные в двоичный файл. Прокладка, вставленная между элементами структуры или класса, может нарушить данные, отправленные в файл или сеть. Чтобы написать переносимый код (тот, который будет использоваться для нескольких разных компиляторов), вам, вероятно, придется обращаться к каждому элементу структуры отдельно, чтобы обеспечить надлежащую «упаковку».
С другой стороны, разные компиляторы имеют разные возможности для управления упаковкой структуры данных. Например, в Visual C / C ++ компилятор поддерживает команду #pragma pack. Это позволит вам настроить упаковку и выравнивание данных.
Например:
#pragma pack 1
struct MyStruct
{
int a;
char b;
int c;
short d;
} myData;
I = sizeof(myData);
Теперь я должен иметь длину 11. Без прагмы я мог бы быть чем угодно из 11 до 14 (а для некоторых систем - до 32), в зависимости от стандартной упаковки компилятора.
6 ответов
Вот мой список причин, почему код - позади может быть полезен взятый из моего собственного сообщения. Я уверен, что существует намного больше.
- Привязка данных средств управления ASP.NET прежней версии - если альтернатива не доступна или временное решение, необходима.
- Просмотрите логику, которая требует, чтобы рекурсия создала некоторый вложенный или иерархический HTML.
- Просмотрите логику, которая использует временные переменные. Я отказываюсь определять локальные переменные в своем супе тега! Я хотел бы их как свойства на классе представления по крайней мере.
- Логика, которая характерна только для одного представления или модели и не принадлежит HtmlHelper. Как примечание стороны я не думаю, что HtmlHelper должен знать о любых 'Образцовых' классах. Его штраф, если это знает о классах, определенных в модели (таких как IEnumerable, но я не думаю, например, что у Вас должен когда-либо быть HtmlHelper, который берет ProductModel. Методы HtmlHelper заканчивают тем, что стали видимыми от ВСЕХ Ваших представлений, когда Вы вводите Html+dot, и я действительно хочу минимизировать этот список как можно больше.
- Что, если я хочу написать код, который использует HtmlGenericControl и другие классы в том пространстве имен для генерации моего HTML объектно-ориентированным способом (или у меня есть существующий код, который делает это, что я хочу портировать).
- Что, если я - планирование использования механизма другого представления в будущем. Я мог бы хотеть сохранить часть логики кроме супа тега, чтобы помочь снова использовать позже.
- Что, если я хочу смочь переименовать свои Образцовые классы и иметь его автоматически, осуществляет рефакторинг мое представление, не имея необходимость переходить к view.aspx и изменять имя класса.
- Что, если я координирую с разработчиком HTML, которому я не доверяю, чтобы не испортить 'суп тега' и хотеть записать что-либо вне очень простого цикличного выполнения в .aspx.cs файле.
- Если Вы хотите отсортировать данные, основанные на опции сортировки по умолчанию представления. Я действительно не думаю, что контроллер должен сортировать данные для Вас, если у Вас есть несколько опций сортировки, доступных только от представления.
- Вы на самом деле хотите отладить логику представления в коде, что actuallky похож на .cs и не HTML.
- Вы хотите написать код, который может быть факторизован позже и снова использован в другом месте - Вы просто не уверены все же.
- Вы хотите моделировать то, что может стать новым HtmlHelper, но Вы еще не решили ли его достаточно дженерик или не гарантировать создание HtmlHelper. (в основном то же как предыдущая точка)
- Вы хотите создать вспомогательный метод представить частичное представление, но должны создать модель для него путем щипания данных из представления основной страницы и создания модели для частичного управления, которое основано на повторении токовой петли.
- Вы полагаете, что программирование сложной логики В ЕДИНСТВЕННОЙ ФУНКЦИИ является устаревшим и неудобной в сопровождении практикой.
- Вы сделали это перед RC1 и не сталкивались ни с какими проблемами!!
Да! Для некоторых представлений не должен быть нужен codebehind вообще.
Да! Это сосет для получения глупого .designer файла, созданного в дополнение к .cs файлу.
Да! Его довольно раздражающее для получения их мало + подписывается рядом с каждым представлением.
НО - Это действительно не что трудно НЕ поместить логику доступа к данным в код - позади.
Они являются несомненно НЕ злыми.
В конечном счете вопрос, который Вы задаете сами, является этим:
Делает этот код A) Процесса, хранят, получают, выполняют операции на или анализируют данные, или B) Справку для отображения данных?
Если ответ является A, он принадлежит Вашего контроллера. Если ответ является B, то он принадлежит представления.
Если B, это в конечном счете становится вопросом стиля. Если Вы переносите некоторые довольно долгие условные операции для попытки выяснить, отображаете ли Вы что-то пользователю, то Вы могли бы скрыть те условные операции в коде позади в Свойстве. Иначе кажется, что большинство людей отбрасывает код, встроенный к фронтэнду с помощью <% %> и <% = %> теги.
Первоначально, я вставил всю свою логику дисплея <% %> теги. Но недавно я взял к помещению чего-либо грязного (такого как длинное условное выражение) в моем коде позади для содержания моего XHML в чистоте. Прием здесь является дисциплиной - слишком заманчиво начать писать бизнес-логику в коде позади, который является точно, что Вы не должны делать в MVC.
При попытке переместить от традиционного ASP.NET до ASP.NET MVC, Вы могли бы избежать кода behinds, пока у Вас нет чувства для методов (хотя это все еще не мешает Вам вставить бизнес-логику <% %>.
Нет цели. Просто не используйте его за исключением установки модели
ViewPage<Model>
Посмотрите это сообщение в блоге для большего количества информации.
В этом Сообщении в блоге рабочий пример удаления кода позади. Единственная проблема, с которой я застреваю, состоит в том, что это не может установить пространства имен на классе.
codebehind обеспечивает часть строгого контроля типов, а также поддержки intellisense, что Вы входите в представление. Если Вы не заботитесь ни об одной из этих двух функций, можно удалить его.
Например, я обычно использую NVelocity ViewEngine, потому что это является чистым и довольно прямым.
Это - большой вопрос. Не делает MVC, существуют в среде ASP.NET, не используя определенный шаблон MVC.
Представление = aspx
Контроллер = aspx.cs (codebehind)
Модель = ПОСТЕПЕННО (Простые объекты C#/VB/.NET)
Я задаюсь вопросом, почему добавленная функциональность платформы MVC полезна. Я значительно работал с Java без обозначения даты MVC и Struts Java несколько лет назад (2001), и нашел, что понятия в MVC были решением для организации интернет-приложения и проблем разработки в то время, но затем нашел, что codebehind упростил понятие контроллера и был более быстрым, чтобы разработать и связаться с другими. Я уверен, что другие не соглашаются со мной, и я открыт для других идей. Самое большое значение, которое я вижу к MVC, является шаблоном фронтального контроллера для интернет-разработки, однократным источником для интернет-приложения. Но с другой стороны, тот шаблон довольно прост реализовать с текущими технологиями ASP.NET. Я услышал, что другие говорят, что Поблочное тестирование является обоснованием. Я могу понять, что также, мы использовали JUnit с нашей платформой MVC в 2001; но я не был убежден, что это упрощает тестирование для использования te MVC платформа.
Спасибо за чтение!