уроки извлечены или ошибки, сделанные при использовании asp.net mvc
Главным образом, да.
трудность с триггером состоит в том, что он действительно наполняет "за Вашей спиной"; разработчик, поддерживающий приложение, не мог легко понять, что это там, и внесите изменения, которые завинчивают вещи без того, чтобы даже замечать.
Это создает слой сложности, которая просто добавляет работы по техническому обслуживанию.
Вместо того, чтобы использовать триггер, хранимая процедура / стандартная программа, может обычно делаться сделать то же самое, но ясным и удобным в сопровождении способом - вызов сохраненной стандартной программы означает, что разработчик может посмотреть на ее исходный код и видеть точно, что происходит.
10 ответов
- Используйте Html. Encode () везде, где вы печатаете данные, если у вас нет веских причин не делать этого, поэтому вам не нужно беспокоиться о XSS
- Не жестко кодируйте маршруты в ваших представлениях или javascripts - они изменятся в какой-то момент используйте вместо него Url.Action ()
- Не бойтесь использовать частичные представления
- MVC - не панацея, сначала оцените, действительно ли это лучший инструмент для решения вашей проблемы.
По возможности делайте ваше представление типизированным
Избегайте логики в ваших представлениях
держитесь подальше от HttpContext
Не используйте коллекцию форм, используйте привязку модели.
Старайтесь не использовать ViewData, создайте ViewModel.
Если у вас есть цикл или if в вашем представлении, напишите помощник HTML.
Доброта,
Дэн
Не позволяйте вашему контроллеру стать толстым и делать слишком много работы. Я видел более 1000 линейных контроллеров в прошлом, и понять, что происходит, становится просто кошмаром.
Используйте модульное тестирование для своих контроллеров, чтобы гарантировать, что зависимости находятся под контролем и что ваш код можно тестировать.
Не позволяйте jQuery и причудливому клиентскому скрипту определять поведение вашего приложения, старайтесь использовать его как можно реже и вместо этого позвольте ему улучшить ваше приложение.
По возможности используйте частичные представления и помощники HTML, чтобы убедиться, что ваш Представления не становятся громоздкими и не становятся кошмаром обслуживания.
По возможности используйте ViewModel.
Используйте структуру внедрения зависимостей для обработки ваших зависимостей (MvcContrib имеет несколько фабрик контроллеров, хотя и
Старайтесь всегда использовать ViewModel для передачи данных между контроллером и представлением. Вы можете подумать, что он вам не нужен, вы можете просто передать свою модель, но внезапно вам понадобится список с несколькими вариантами для редактирования модели или отображения сообщения (не сообщения проверки), и вы начинаете добавлять элементы в ViewData , с волшебными строками в качестве ключей, что усложняет обслуживание приложения. Есть также некоторые проблемы безопасности, которые вы решаете с помощью ViewModel. Например:
class user:
int id
string name
string email
string username
string password
Ваше представление позволяет пользователю изменить свое имя и адрес электронной почты и отправить сообщение в действие
public ActionResult Edit(User user)
{
--persist data
}
Кто-то может подделать вашу форму и опубликовать новый пароль и имя пользователя, и вам нужно будет быть очень осторожным с поведением DefaultBinder. Теперь, если вы используете ViewModel, например:
class userEditViewModel:
int id
string name
string email
, проблема исчезла.
Получить Стив Сандерсонс Pro ASP.NET MVC Framework
Отладка в Исходный код
Используйте разные контроллеры для каждого раздела вашего сайта (например, «Дом», «Аккаунт»)
Узнайте, как использовать ViewData и TempData.
Узнайте, что использование RenderPartial
- Если вы создадите метод Controller с именем параметра, отличным от id для метода с одним параметром, вам придется создать новый маршрут. Просто возьмите и используйте id (ему не важен тип) и объясните это в комментариях.
Убедитесь, что вы назвали свои параметры с помощью
RedirectToAction:return RedirectToAction("DonateToCharity", new { id = 1000 });