На самом деле, POCO все же обычно отличают от DTO, потому что POCO это не просто там класс, а класс моделирующий домен. Он содержит в себе не только данные но и поведение. Это принципиальное отличие см например статью об анемичной доменной модели.
Это означает, что если не очень долго сидеть и смотреть на траффик, можно получить пару сообщений заксоренных с одним и тем же pseudo_pad. SessionId начнет дублироваться через 2^16 пакетов.
Классические ошибки конструирования шифров… Отсутствие защиты от MitM — без комментариев. Ну и использовать в качестве псевдо случайного генератора MD5 — тоже заводно.
Тот же Макконел не рекомендует увлекаться множественными выходами из метода. (Вернее в одном месте книги он рекомендует делать это, а в другом советует не увлекаться).
Набор UseCase это несомненно важная часть тз, но далеко не единственная. Не менее важной частью (как минимум) является E-R диаграмма (диаграмма сущности-связи).А кроме того, в тз должны быть нефункциональные требования (например требования на отзывчивость системы), скетчи интерфейса, и т.п.
Мне не очень понятно, какой смысл сейчас использовать md5 hash? В нем брутфорсом можно сейчас коллизию найти. Его имеет смысл использовать только если у вас legacy система, которая ничего более современного не умеет.
Может все же не брать пузырьковую сортировку, а взять алгоритм сортировки с временем n*log(n)? Например quicksort или mergesort. Тогда у вас не будет 2 вложенных цикла по миллиарду.
Мне кажется, тут нет смысла говорить о политике Microsoft. Если бы это была политика Microsoft, тут был бы Unity или MEF2. Просто команде разрабатывающей MVC захотелось написать свой собственный контейнер с блекджеком. Ну бывает. Бтв, я не заметил, чтобы Unity везде пихали (в смысле настойчиво продвигали). EntityFramework с этой точки зрения более навязчив (по умолчанию добавленный пакет в ASP.Net MVC шаблон проекта).
Я то надеялся, что мне расскажут какие новые возможности в контексте MVC приложения дает этот контейнер, по сравнению с другими, но что-то единственное преимущество которое привели — искоробочность, которое я за преимущество не считаю.
Да, в случае голой заливки данных (я не говорю про запросы), INSERT в CacheSQL всегда будет медленнее чем прямая манипуляция глобалом, т.к. добавляется некоторый объем дополнительной работы необходимый для эмуляции ACID. Программист, работающий с глобалом напрямую обычно игнорирует некоторую транзакционную строгость, выигрывая по скорости. Иногда, при первичной загрузке данных, или в монопольном режиме на это можно закрыть глаза.
То есть все же полная функциональность не сохраняется? Так зачем вы об этом пишете?
Если б он еще умел все то, что умеют остальные контейнеры… Вот что у него, например, с внедрением Func, если мы зарегистрировали T? Ну и да, а если я вообще не хочу тащить контейнер, а хочу Pure DI? Нафига мне это в инфраструктуре? Учитывая, что в MVC DI контейнер встраивался легко и не принужденно то ли с первой то ли со второй версии, зачем было тратить время на эту разработку не понятно.
смотреть ответы.
Там есть принятый сообществом ответ и непринятый сообществом ответ, который ссылается на англоязычную версию этой статьи.
Ну это нормально. Надо же чтобы на него обратили внимание и попробовали.
Я то надеялся, что мне расскажут какие новые возможности в контексте MVC приложения дает этот контейнер, по сравнению с другими, но что-то единственное преимущество которое привели — искоробочность, которое я за преимущество не считаю.
То есть все же полная функциональность не сохраняется? Так зачем вы об этом пишете?