То есть диспетчеризация происходит по первому типу-параметру. Так как это все происходит в compile-time, то есть никакого runtime полиморфизма, то чем это лучше, чем:
v4.callMethod1(0, 1);
v4.callMethod0(10, 31);
?
При этом callMethodX можно заменить на нормальные имена, а внутри будет банальный pimpl, возможно с typetest, и не нужны будут все эти пляски с кучей шаблонов.
Notepad — нативное приложение, его рефлектором не откроешь. Но по исходникам вполне можно разобраться что к чему.
Для .NET код все проще, рефлектор очень помогает. Код шарика я именно рефлектором изучал, он дает на несколько порядков больше понимания, чем любая документация и гайды. ASP.NET MVC, особенно первых версий, очень простая вещь и нет проблем изучить как оно работает.
При чем тут качество я не понял. Нужно не абстрактное качество, а реализация конкретных сценариев.
И как доказательство сырости WF, ваши же слова: «Начиная с версии sharepoint 2013 для WF используется отдельный сервер, который нужно использовать и в своих приложениях». Осталось дело за малым — тем пацанам из 2005-го прислать машину времени и дать sharepoint 2013 :)
Машины времени не существует, но это не означает что в 2013 году надо свой код писать так, как посоны из МС предполагали писать в 2005, не находите?
Авторы может и не медиумы, но сегодня есть куча примеров применения технологии и как-то неправильно на них не смотреть. Или у вас другое мнение?
Если будет много plan guides, то проблема вовсе не в ef.
Еще раз повторю слова поста — Linq позволяет описать только очень простые запросы, которые прекрасно оптимизируются SQL Server и Oracle. Если СУБД не оптимизирует запрос, то значит не хватает индексов\статистики\ограничений. Поэтому хинты вряд ли нужны будут. NOLOCK тоже не нужно ставить, лучше запросы оптимизировать, чтобы интервал блокировок был меньше. На крайний случай установить уровень изоляции read uncommitted. А в идеале поставить RCS.
Видео на тот момент было от силы десятка два роликов от 2 до 20 минут. Напомню что CTP версия, еще ничего не было.
Код смотрел рефлектором, для ASP.NET MVC первой версии было его совсем немного, сумарно пару тыщ LOC, достойных внимания. Ушло на это примерно неделя.
Метрика достаточности знаний субъективная — когда очко перестает играть от мысли применения технологии в реальном проекте. некоторые вещи МС я бы до сих пор не взялся в реальном проекте применить.
Выбора между пятью обычно нет, есть выбор использовать готовое или наструячить свое. В этом случае имеет смысл потратить на изучение, ибо даже если струячить свое, то можно многому научиться разбираясь как работает существующая технология.
Если все изучение начинается и заканчивается маркетинговыми материалами, то да, фраза кажется несуразной.
Но я как-то привык читать код и анализировать готовые решения ДО того, как кидаться применять технологию.
Например до применения ASP.NET MVC еще CTP версии, по которой не было никаких реальных примеров, я изучил ВСЕ видео и дважды просмотрел код рефлектором чтобы понимать чем мне грозит.
RCS все таки лучше nolock
1) Его не надо писать руками
2) Уровень изоляции таки read commited
Именно поэтому EF ставит RCS для новых баз.
Я кстати видел dirty read баги в живой системе, которую «оптимизировали» с помощью nolock. Причем такие баги диагностировать почти нереально ибо весь код отрабатывает в этом случае корректно, а по сути бага была в том что чтение происходило между вставкой строк в одном insert операторе.
SNAPSHOT ISOLATION LEVEL создает по сути слепок данных на момент запроса и удерживает слепок до конца транзакции. Например при чтении таблицы будет создана копия всей таблицы. На самом деле чуть хитрее, копия будет сделана не сразу, а только при записи, но при сильной конкуренции ситуация будет близка к этой.
Это дает изолированность транзакций, то есть нет фантомов, неповторяемых и грязных чтений, но не дает сериализуемости.
READ COMMITED SNAPSHOT заставляет при записи не вешать лок, а делать копию строки, и при коммите заменять основную версию. При чтении никаких локов и копирование строк не происходит. Но работает только на уровне изоляции READ COMMITED, то есть позволяет неповторяемое чтение и фантомы.
Механизм версионирования внутри одинаковый, а применение разное и эффект разный.
Проблемы с обоими SNAPSHOT могут быть при высококонкурентном доступе к одним и тем же данным.
Вот вышел WF — что людям делать? Пытать Гейтса «где он у вас заюзан»?
Именно. Если технология не прошла догфудинг в МС, то скорее всего в первой версии будет неюзабельна.
И вот автор и применил — не вижу ничего криминального в том, что человек описал все грабли, на которые наступил благодаря «проталкиванию» продукта микрософтом.
Я вижу недостаток, что автор использует неверный подход, при этом ругает технологию. К сожалению МС не озаботились дать верный подход, его приходится выковыривать из продуктов.
Все дело в Include
1) Бага в EF, описана в этом посте в мифе #2
2) Надо делать проекции, ибо при джоине двух таблиц без проекций генерируется довольно большой Dataset.
Нельзя закладываться во что преобразуются функции, это надо проверять и смотреть в документации, а если не писать функции, то Linq ничего в предикате не сгенерит.
Вообще если из А следует Б, то это не значит что из Б следует А. ;)
То есть диспетчеризация происходит по первому типу-параметру. Так как это все происходит в compile-time, то есть никакого runtime полиморфизма, то чем это лучше, чем:
?
При этом callMethodX можно заменить на нормальные имена, а внутри будет банальный pimpl, возможно с typetest, и не нужны будут все эти пляски с кучей шаблонов.
Или я что-то не понимаю?
Для .NET код все проще, рефлектор очень помогает. Код шарика я именно рефлектором изучал, он дает на несколько порядков больше понимания, чем любая документация и гайды. ASP.NET MVC, особенно первых версий, очень простая вещь и нет проблем изучить как оно работает.
При чем тут качество я не понял. Нужно не абстрактное качество, а реализация конкретных сценариев.
Машины времени не существует, но это не означает что в 2013 году надо свой код писать так, как посоны из МС предполагали писать в 2005, не находите?
Авторы может и не медиумы, но сегодня есть куча примеров применения технологии и как-то неправильно на них не смотреть. Или у вас другое мнение?
Еще раз повторю слова поста — Linq позволяет описать только очень простые запросы, которые прекрасно оптимизируются SQL Server и Oracle. Если СУБД не оптимизирует запрос, то значит не хватает индексов\статистики\ограничений. Поэтому хинты вряд ли нужны будут. NOLOCK тоже не нужно ставить, лучше запросы оптимизировать, чтобы интервал блокировок был меньше. На крайний случай установить уровень изоляции read uncommitted. А в идеале поставить RCS.
Но вот чего точно не надо делать — пытаться адаптировать производственный конвейер, как в макдаке, под задачи разработки, не взлетит.
Код смотрел рефлектором, для ASP.NET MVC первой версии было его совсем немного, сумарно пару тыщ LOC, достойных внимания. Ушло на это примерно неделя.
Метрика достаточности знаний субъективная — когда очко перестает играть от мысли применения технологии в реальном проекте. некоторые вещи МС я бы до сих пор не взялся в реальном проекте применить.
Выбора между пятью обычно нет, есть выбор использовать готовое или наструячить свое. В этом случае имеет смысл потратить на изучение, ибо даже если струячить свое, то можно многому научиться разбираясь как работает существующая технология.
Но я как-то привык читать код и анализировать готовые решения ДО того, как кидаться применять технологию.
Например до применения ASP.NET MVC еще CTP версии, по которой не было никаких реальных примеров, я изучил ВСЕ видео и дважды просмотрел код рефлектором чтобы понимать чем мне грозит.
1) Его не надо писать руками
2) Уровень изоляции таки read commited
Именно поэтому EF ставит RCS для новых баз.
Я кстати видел dirty read баги в живой системе, которую «оптимизировали» с помощью nolock. Причем такие баги диагностировать почти нереально ибо весь код отрабатывает в этом случае корректно, а по сути бага была в том что чтение происходило между вставкой строк в одном insert операторе.
Это дает изолированность транзакций, то есть нет фантомов, неповторяемых и грязных чтений, но не дает сериализуемости.
READ COMMITED SNAPSHOT заставляет при записи не вешать лок, а делать копию строки, и при коммите заменять основную версию. При чтении никаких локов и копирование строк не происходит. Но работает только на уровне изоляции READ COMMITED, то есть позволяет неповторяемое чтение и фантомы.
Механизм версионирования внутри одинаковый, а применение разное и эффект разный.
Проблемы с обоими SNAPSHOT могут быть при высококонкурентном доступе к одним и тем же данным.
Именно. Если технология не прошла догфудинг в МС, то скорее всего в первой версии будет неюзабельна.
Я вижу недостаток, что автор использует неверный подход, при этом ругает технологию. К сожалению МС не озаботились дать верный подход, его приходится выковыривать из продуктов.
1) Бага в EF, описана в этом посте в мифе #2
2) Надо делать проекции, ибо при джоине двух таблиц без проекций генерируется довольно большой Dataset.
Вообще если из А следует Б, то это не значит что из Б следует А. ;)