Смотрите, тут дело еще может быть в том, что люди (а заказчики — особливо) реально не видят профитов от правильного написания. И с ними очень сложно спорить по этому вопросу, ибо как технически — да, можно запихать всю логику в один контроллер. И таки да — это будет работать. К сожалению, даже в нашей индустрии людей, просчитывающих свои действия на 2-3 шага вперед довольно немного. И зачастую, для того чтобы человек осознал что надо писать правильно — ему требуется «доказательство от противного» — e.g. пронаблюдать хотя бы один проект, у которого maintainability cost превысила net income, что привело к банкротству стартапа/заказчика/watever. Я не говорю что все такие, но по моим наблюдениям в России таких довольно-таки много.
Чушь! Я видел очень много людей с высшим образованием, пишущих дурного качества код. Знаете к чему приводит переизбыток образования при неумении писать простой и эффективный код? Правильно — к «русскому коду». Русский код — это когда у тебя есть абстрактная фэктори для сервиса с единственным публичным методом, который вычисляет факториал используя частичную LINQ-выборку из бесконечного генератора чисел (который на yield return построен).
Представьте что эти носители высшего образования пишут на более серьезных задачах.
Так что высшее образование зачастую приводит к повышенному желанию наличие этого самого высшего образование продемонстрировать. То есть не гарантия.
Во во. Держу пари, что когда вы это задание выполнили — где-то в мире заплакал один разработчик, которому придется этот тест в итоге заигнорить или удалить, потому что окружает его такое дерьмо, что непонятно как это все еще работает :)
Раз уж речь о unit-тестах, то я еще 5 копеек добавлю: подобные конторы/команды любят на собеседованиях спрашивать «а вы умеете писать unit-тесты?» и в вакансиях утверждать «мы используем TDD и без него никуда!».
Але, уважаемые. Довожу оперативно до вашего сведения, что для того, чтобы писались unit-тесты, система должна на эти самые unit-ы легко разделяться! А не быть монолитным куском, который за собой тянет маленькую галактику и не отрезается от БД.
Практика тут показывает что если в решении не используется в каком-либо виде инверсия контроля и разрешение зависимостей — то такой системе надо титьку сосать архитектурный рефакторинг провести. А не unit-тесты писать.
От себя (дотнетчик) добавлю, что люди не знают и не умеют оперировать готовыми стеками. Вот для .NET/MVC он например есть. ORM, сервисы, IoC, автомаппер. Просто, как три копейки. Нет жешь блин! Приходишь в каждый проект и там то статика сплошная, то on-demand люди создают себе инстансы чего-то отдаленно похожего на сервисы, то просто подключение к БД пробрасывают в контроллеры (хорошо если одно на запрос!) и фигачат прямым SQL-ем. Воистину понимаешь, что те, кто запилил свой IoC-фреймворк — с теми хотя бы работать можно.
То добавляют абсолютно лишние слои абстракции так, что от этих абстракций потом не избавишься. А еще — самый смак — если у команды есть unit-тесты. Такие, знаете, выстраданные и политые кровью и потом unit-тесты. Они, конечно, не падают когда возникают ошибки логики. Все чаще, знаете ли, тестируют на живой базе как отработал EF-ный .SaveChanges (да да, интеграционные тесты у нас часто по ошибке называют unit-тестами). И вот когда ты начинаешь архитектурный рефакторинг — тесты в лучшем случае выкидываются. Но иногда менеджменту, рьяно отстаивавшему необходимость unit-тестов в проекте «ну чтобы типа все безопасно было, чтобы при каждой сборке вот мы проверяли что система работает, TDD» — становится жалко потраченное время и бабло. И в этом случае тесты при архитектурном рефакторинге на ровном месте создают вдвое больший объем работы, чем был бы без них. Все правильно: разгреб навоз в коде — разгреби и в тестах, которые к тому моменту обычно перестают собираться.
Да да да. Я полностью поддерживаю автора — урезаешь ненужный код — остается 3,5 метода логики и пара классов.
А самое что вымораживающее — так это то, что каждый проект люди начинают «с нуля». Ну то есть с нуля определяются конвенции для разбиения системы на слои, (пере)осмысляется политика использования транзакций, используемые фреймворки подбираются по принципу «о, я слышал о такой штуковине — давайте изучим!», опять говориться о unit-тестах — ну конечно же, изобретаются велосипеды и используется все, что попалось под руку по принципу «ну мы же непрерывно учимся — вот, фреймворк новый пробуем». Зато в полном соответствии с гибкими методологиями! «У нас нет системного архитектора — у нас же SCRUM» — сколько раз я уже такое слышал…
Словом, фуфуфу такими быть.
При всем обилии адептов Windows, которые плачутся что Linux слишком сложен, я впервые вижу линуксоида, который плачется что windows слишком сложен. Как говорится, не думал что доживу до этого момента.
Я еще раз повторюсь — такие вещи можно сделать десятком разных способов — хоть через edmx с T4. Однако наша основная дискуссия была на тему того, что без деревьев выражений не бывает нормальной конфигурации в коде. EF использовался для иллюстрации этого утверждения. Видимо, не очень хороший пример, ладно. Надо было указать на Moq, automapper или любой другой фреймворк на fluent-конфигурации.
Никто не спорит. Но я имею наглость полагать, что коль у MS хватило духу перенести .NET-рантайм в браузер, то неплохо бы собрать яйца в кучку и довести дело до конца, доработав инфраструктуру передачи данных до состояния, когда он будет демонстрировать шокирующую простоту и скорость разработки не только на проектах уровня Hello World.
Да можно и свой edmx сдуру написать руками :) Вопрос в том, что удобнее. Аннотации неудобны, потому что размазывают конфигурацию по всему коду — и потом ищи свищи где ты там [Column] поставил. К тому же статической проверки типов там нет.
Fluent-конфигурация удобна тем, что её можно комбинировать через поведенческие примеси, что позволяет легко и непринужденно, например, выносить общую конфигурацию для каких-либо специфических и похожих сущностей в отдельный обобщенный метод. У нас в проекте например довольно много сущностей с полем Name (помимо Id). И все они у нас 128 байт в длину, типа nvarchar, не допускающие пустых строк. Все они конфигурируются через один и тот же метод конфигурации, что весьма удобно.
Эмм… альтернативой Silverlight является приложение — извините — на flash. Сейчас уже можно на голом JS (во времена Silverlight ни angularjs, ни react не было). В самом хардкорном случае C#-код исполнялся в браузере — это уже ActiveX-ом попахивает. Ну или да — или NPAPI. Я знаю про WCF RIA довольно много и как инструмент пробрасывания запросов он, извините, неудобен.
Не совсем. F# появился, насколько я врубаюсь, скорее от желания MS повыкабениваться в пору повального увлечения всех функциональным программированием. Его, я думаю, можно не считать. Ну серьезно — это как если бы Scala сделал сам Oracle.
VB.NET появился для удовлетворения одной объективной потребности — миграции внушительного количества леммингов legacy-пользователей VB6 на .NET, которым учить С-like язык хуже горькой редьки. Авторство так же за самим Microsoft.
Ваше замечание было бы хорошим аргументом, если бы вы упомянули, скажем, Nemerle или Boo :). Но вот беда — оба они широкого распространения не получили и так и остались на уровне такого своеобразного концепта, который люди реферируют в пламенных интернет-дискуссиях, когда надо подчеркнуть богатство возможностей CLR/CTS/CIL. Не встречал ни одного человека, который использовал бы оные в продакшене. Nemerle бедный — так вообще загнулся в развитии по ходу дела и остался притчей во языцех и интересным материалом для теоретических исследований.
Ну т.е. под .NET не было такого случая, когда команда сторонних по отношению к платформе людей заявляет с огромной помпой что вот, мол, сейчас мы сделаем самый-лучший-язык для JVM, который будет лучше чем Java. И в результате получается Scala или Kotlin, который активно начинает использоваться в живом продакшне и в который влюбляются тысячи разработчиков — уж не знаю плохо это или хорошо.
То есть поймите меня правильно, за столько лет ничего лучше чем C# для продакшна и массового использования придумать не удалось :)
Ну дык… Про Unity можно доступно объяснить, мол, пока вот это кнопку не жмакнешь — игруленька не запустится. И пользователь жмакает, потому что хочет игруленьку. Проделывать то же самое, например, для видеоплеера он наотрез откажется, ибо как ему это видео при наличии ютуба никуда не уперлось :) Ну это сугубо ИМХО.
WCF RIA, на сколько я помню, был нужен обязательно для работы с датагридами от Silverlight. И вот пересадить оные на DTO вместо прямого подключения к контексту данных EF/Linq2Sql, да еще и попутно внедрить IoC привносило некоторый геморрой и нотку сюрреализма в решаемую задачу. Дело было давно, всех деталей уже не упомню, но я взялся тогда писать внутреннюю корпоративную админку для одного веб-сайта на этом стеке и меня постигла боль и разочарование при том, что изначально технология смотрелась весьма вкусно. Полагаю, я не один такой был.
Извините, не в mscorlib конечно же, а где-либо в вашем приложении. Это как если бы работоспособность операции "+" зависела от того, какие у вас references. Ну то есть само по себе это не плохо и не хорошо, однако если у вас такая ситуация наличествует, то я бы не стал картинно напирать на понимание различий между языком и рантаймом.
Я знаю. Но факт в том, что если в mscorlib этого не упомянуть — не заведется. Вот я о чем. В этом плане async/await не являются чисто языковыми конструкциями
Представьте что эти носители высшего образования пишут на более серьезных задачах.
Так что высшее образование зачастую приводит к повышенному желанию наличие этого самого высшего образование продемонстрировать. То есть не гарантия.
Але, уважаемые. Довожу оперативно до вашего сведения, что для того, чтобы писались unit-тесты, система должна на эти самые unit-ы легко разделяться! А не быть монолитным куском, который за собой тянет маленькую галактику и не отрезается от БД.
Практика тут показывает что если в решении не используется в каком-либо виде инверсия контроля и разрешение зависимостей — то такой системе надо
титьку сосатьархитектурный рефакторинг провести. А не unit-тесты писать.То добавляют абсолютно лишние слои абстракции так, что от этих абстракций потом не избавишься. А еще — самый смак — если у команды есть unit-тесты. Такие, знаете, выстраданные и политые кровью и потом unit-тесты. Они, конечно, не падают когда возникают ошибки логики. Все чаще, знаете ли, тестируют на живой базе как отработал EF-ный .SaveChanges (да да, интеграционные тесты у нас часто по ошибке называют unit-тестами). И вот когда ты начинаешь архитектурный рефакторинг — тесты в лучшем случае выкидываются. Но иногда менеджменту, рьяно отстаивавшему необходимость unit-тестов в проекте «ну чтобы типа все безопасно было, чтобы при каждой сборке вот мы проверяли что система работает, TDD» — становится жалко потраченное время и бабло. И в этом случае тесты при архитектурном рефакторинге на ровном месте создают вдвое больший объем работы, чем был бы без них. Все правильно: разгреб навоз в коде — разгреби и в тестах, которые к тому моменту обычно перестают собираться.
Да да да. Я полностью поддерживаю автора — урезаешь ненужный код — остается 3,5 метода логики и пара классов.
А самое что вымораживающее — так это то, что каждый проект люди начинают «с нуля». Ну то есть с нуля определяются конвенции для разбиения системы на слои, (пере)осмысляется политика использования транзакций, используемые фреймворки подбираются по принципу «о, я слышал о такой штуковине — давайте изучим!», опять говориться о unit-тестах — ну конечно же, изобретаются велосипеды и используется все, что попалось под руку по принципу «ну мы же непрерывно учимся — вот, фреймворк новый пробуем». Зато в полном соответствии с гибкими методологиями! «У нас нет системного архитектора — у нас же SCRUM» — сколько раз я уже такое слышал…
Словом, фуфуфу такими быть.
Само собой. Однако если не интересуешься, то кроме Oracle ничему и не научат. Именно на это одностороннее освещение я и указывал.
Я тоже писал графику на MFC. Сейчас Java с возможностью выбора.
Ну и зачем? Люди деньги потратили, купили, а тут внутри все отказываются использовать, мотивируя это… чем?
Fluent-конфигурация удобна тем, что её можно комбинировать через поведенческие примеси, что позволяет легко и непринужденно, например, выносить общую конфигурацию для каких-либо специфических и похожих сущностей в отдельный обобщенный метод. У нас в проекте например довольно много сущностей с полем Name (помимо Id). И все они у нас 128 байт в длину, типа nvarchar, не допускающие пустых строк. Все они конфигурируются через один и тот же метод конфигурации, что весьма удобно.
VB.NET появился для удовлетворения одной объективной потребности — миграции внушительного количества
лемминговlegacy-пользователей VB6 на .NET, которым учить С-like язык хуже горькой редьки. Авторство так же за самим Microsoft.Ваше замечание было бы хорошим аргументом, если бы вы упомянули, скажем, Nemerle или Boo :). Но вот беда — оба они широкого распространения не получили и так и остались на уровне такого своеобразного концепта, который люди реферируют в пламенных интернет-дискуссиях, когда надо подчеркнуть богатство возможностей CLR/CTS/CIL. Не встречал ни одного человека, который использовал бы оные в продакшене. Nemerle бедный — так вообще загнулся в развитии по ходу дела и остался притчей во языцех и интересным материалом для теоретических исследований.
Ну т.е. под .NET не было такого случая, когда команда сторонних по отношению к платформе людей заявляет с огромной помпой что вот, мол, сейчас мы сделаем самый-лучший-язык для JVM, который будет лучше чем Java. И в результате получается Scala или Kotlin, который активно начинает использоваться в живом продакшне и в который влюбляются тысячи разработчиков — уж не знаю плохо это или хорошо.
То есть поймите меня правильно, за столько лет ничего лучше чем C# для продакшна и массового использования придумать не удалось :)
Вот список языков, о которых вы никогда не слышали и не станете использовать в продакшне
WCF RIA, на сколько я помню, был нужен обязательно для работы с датагридами от Silverlight. И вот пересадить оные на DTO вместо прямого подключения к контексту данных EF/Linq2Sql, да еще и попутно внедрить IoC привносило некоторый геморрой и нотку сюрреализма в решаемую задачу. Дело было давно, всех деталей уже не упомню, но я взялся тогда писать внутреннюю корпоративную админку для одного веб-сайта на этом стеке и меня постигла боль и разочарование при том, что изначально технология смотрелась весьма вкусно. Полагаю, я не один такой был.