Как Вы имеете дело с новыми возможностями C# так, чтобы они не приводили к плохо написанному коду?
В asp.net-mvc вы не можете связать напрямую с представлением, вам нужно действие контроллера поддержки:
public class HomeController : Controller
{
public ActionResult Index()
{
ViewBag.Title = "Home Page";
return View();
}
public ActionResult BookingChamb()
{
return View();
}
}
А затем сгенерируйте вашу ссылку с помощью:
@Html.ActionLink("Booking","Home","BookingChamb")
9 ответов
Объектные инициализаторы просто позволяют клиенту сразу установить свойства после того, как конструкция, никакое управление не оставлено, поскольку вызывающая сторона должна все еще удостовериться, что все аргументы конструктора удовлетворены.
Лично я чувствую, что они добавляют очень мало:
Person p1 = new Person("Fred");
p1.Age = 30;
p1.Height = 123;
Person p2 = new Person("Fred")
{
Age = 30;
Height = 123;
};
Я знаю, что большому количеству людей не нравится ключевое слово 'var'. Я могу понять, почему, поскольку это - открыто привлекательное злоупотребление, но я не возражаю, это обеспечивающий тип ослепляюще очевидно:
var p1 = new Person("Fred");
Person p2 = GetPerson();
Во второй строке выше, тип не очевиден, несмотря на имя метода. Я использовал бы тип в этом случае.
Дополнительные методы - я использовал бы очень экономно, но они очень полезны для расширения типов.NET с удобными методами, особенно IEnumerable, ICollection и Строка. Строка. IsNullOrEmpty () как дополнительный метод очень хорош, как это можно назвать на нулевых ссылках.
Я не думаю, что необходимо волноваться, хорошие разработчики будут всегда использовать свои инструменты с уважением, и плохие разработчики будут всегда находить способы к misue свои инструменты: ограничение набора инструментов не решит эту проблему.
Я видел Вашу позицию, выраженную как это:
Создайте среду разработки, которую может использовать любой дурак и что Вы получаете, многие дураки, разрабатывающие.
Это очень верно, но остальная часть нас выглядит хорошей, в отличие от этого. Я рассматриваю это как хорошую вещь. Одна из самых забавных регистраций я когда-либо видел отмеченный это
VB не должен быть недооценен. Это - чрезвычайно мощный инструмент для хранения идиотов из этого [C++] группа новостей.
Более серьезно, действительно ли инструменты опасны, зависит от мудрости владельца. единственным путем можно предотвратить безумие, должен предотвратить действие. foreach выглядит безвредным, но Вы не можете даже удалить объекты, поскольку Вы выполняете итерации набора, потому что удаление объекта делает недействительным итератор. Вы заканчиваете тем, что вывели их в пользу классика для цикла.
Вы могли ограничить функции C# 3.0, который Ваши разработчики могут использовать путем записи ограничений в стандарты кодирования. Затем, когда код рассматривается до регистрации, любой код, который нарушает эти правила, должен быть определен и регистрация отказанного. Один такой случай мог быть дополнительными методами.
Очевидно, Ваши разработчики захотят использовать новые функции - все разработчики делают. Однако, если Вы будете иметь хороший, хорошо зарегистрированные причины, почему они не должны использоваться, хорошие разработчики будут следовать за ними. Необходимо также быть открыты для пересмотра этих правил, поскольку новая информация обнаруживается.
С VS 2008 можно указать, для какой версии.NET Вы хотите быть нацеленными (Щелчок правой кнопкой по решению и выбрать Свойства> Приложение). При ограничении себя.NET 2.0 затем, Вы не получите ни одной из новых возможностей в.NET 3.5. Очевидно, это не помогает, если Вы хотите использовать некоторые функции.
Однако я обдумываю Ваши страхи vars являются неоправданными. C# все еще так же со строгим контролем типов как всегда. Объявление чего-то как var просто говорит компилятору выбирать лучший тип для этой переменной. Переменная не может изменить тип, который это всегда int или Person или что бы то ни было. Лично я следую тем же правилам как Paul Ruane; если тип ясен из синтаксиса, затем используют a var; если не называют тип явно.
Я думаю, что единственной действительно выровненной по ширине проблемой в Вашем наборе является злоупотребление дополнительными методами. Когда важная функциональность только доступна через дополнительные методы, иногда всем в группе трудно узнать об и использовать ту функциональность.
Волнение по поводу объектных инициализаторов и ключевого слова "var" кажется очень nitpicky. Оба - простой и предсказуемый синтаксис, который может использоваться для создания кода более читаемым, и мне не ясно, как Вы видите, что они "оскорблены".
Я предлагаю, чтобы Вы обратились к проблемам как это через записанный, согласованный стандарты кодирования. Если никто не может придумать серьезные основания использовать новые функции языка, то нет никакой потребности использовать их, в конце концов.
Объектные инициализаторы являются просто необычным синтаксисом. Нет ничего, что разработчик может сделать с ними, что он не мог уже сделать, прежде - они действительно однако сохраняют Вас несколько строк кода.
Если "расширяются созданный в типах", Вы имеете в виду дополнительные методы - снова, это не ничто нового, просто лучший синтаксис. Методы являются статическими методами, которые появляются, как будто они были участниками. Сборка в классах остается нетронутой.
Неявные переменные определенного типа необходимы для Linq. Я также использую их с дженериками, которые имеют много параметров типа. Но я согласился бы, что не хотел бы видеть их используемый исключительно.
Конечно, каждой функцией можно злоупотребить, но я думаю, что эти новые возможности на самом деле позволяют Вам написать код, который легче прочитать.
Новые возможности были представлены, потому что Microsoft поняла, что они абсолютно необходимы для того, чтобы реализовать новые опции языка. Как LINQ, например. Таким образом, можно использовать ту же стратегию: 1) знайте о тех функциях, 2) не используйте, пока Вы не считали бы это абсолютно необходимым для Вас.
Если бы Вы действительно понимаете те функции, я держал пари, что Вы чувствовали бы это необходимый довольно скоро.:)
По крайней мере, с "var" и инициализаторами Вы действительно не можете сделать что-либо новое, это - просто новый способ записать вещи. Хотя действительно похоже, что объектные инициализаторы компилируют в немного отличающийся IL.
Один угол, который действительно уносит мой ум о дополнительных методах, - то, что можно поместить их на интерфейс. Это означает, что класс может наследовать конкретный код путем реализации интерфейса. И так как класс может реализовать несколько интерфейсов, который означает в окольном виде пути, что C# теперь имеет что-то как множественное наследование. Таким образом, это - новая возможность, которая должна определенно быть обработана с осторожностью.
Один большой фактор смягчения о var - то, что он никогда не может перемещаться между объемами. Это не может быть тип возврата или тип параметра. Это делает это намного более безопасным в моем уме, поскольку это всегда плотно вводится и всегда деталь реализации одного метода.
Мои заботы выравниваются по ширине?
Нет. Это было другим выпуском простых ответов на простые вопросы.