Практические примеры
В продолжение темы предыдущего поста. Поскольку не всем понятно, в чем цимес этой технологии, постараюсь проиллюстрировать на условных примерах.
Пример 1
Представьте себе стандартное банковско-бухгалтерское приложение, в котором есть таблица выданных кредитов. В ней есть, помимо прочего, поле ClientId - ссылка на поле Id в таблице Clients, а также поле MoneyTaken - типа, взят ли реально кредит клиентом или он в итоге от него отказался. Приложение у нас большое, и это поле используется в куче мест. Теперь разработчикам поступил новый заказ - сделать поддержку векселей. Заказчик сказал, что векселя - это те же кредиты, но с боку бантик. Соответственно, разработчики сделали аналогичную таблицу, и в ней тоже сделали такие же поля ClientId и MoneyTaken, после чего 3 недели в поте лица всей командой делали пользовательский интерфейс, расчеты и отчеты. Через 3 недели выясняется, что на самом деле векселя должны ссылаться не на таблицу Clients, а на другую таблицу - Issuers (соответственно, поле ссылки желательно переименовать), а поля MoneyTaken вообще нет.
Что разработчикам делать в ситуации с традиционной технологией через прямое использование SQL? Задолбаться, потому что поиск по исходному коду выдает не только случаи использования ClientId и MoneyTaken в таблице векселей, но и случаи использования этих полей в таблице кредитов, которых намного больше. Придется либо анализировать все эти случаи, либо по памяти вспоминать, где успели использовать новую таблицу, и менять там. А ведь еще нужно в join-ах и вспомогательных запросах заменять Clients на Issuers и думать, что еще сломается из-за такой замены. В любом случае, тестировать нужно будет много и тщательно, и не только функционал, связанный с векселями, но и старый функционал по кредитам, т.к. не исключено, что по невнимательности поле переименуют/удалят в запросе по кредитам.
А что делать в случае использования Code First/LINQ? Встаем на поле ClientId в классе векселей и вызываем рефакторинг Rename. Поскольку средства рефакторинга в языках со статической типизацией довольно умные, то при этом у нас переименуется только поле в этом классе, кредиты останутся незатронутыми. Нам останется только поменять у нового поля тип с Client на Issuer и удалить MoneyTaken, после чего запустить компиляцию. Компилятор сам выдаст нам ошибки во всех местах, где требуются переделки. Час работы - и при этом можно быть уверенным, что функционал по кредитам на будет затронут в ходе переделки.
Пример 2
Предположим, у нас во всех таблицах есть общие поля (Added, AddedBy, LastChanged, LastChangedBy). В традиционной технологии эти поля дублируются во всех таблицах. Соответственно, если нужно добавить новые поля типа AddedByIPAddress и LastChangedByIPAddress, то придется пройтись по всем таблицам, а также по всем запросам insert и update. Это работа на много часов. В Code First/LINQ у нас все классы будут просто унаследованы от одного базового класса, и функционал по заполнению его полей также будет сконцентрирован в одном методе, поэтому добавление новых полей можно будет сделать один раз.
Пример 1
Представьте себе стандартное банковско-бухгалтерское приложение, в котором есть таблица выданных кредитов. В ней есть, помимо прочего, поле ClientId - ссылка на поле Id в таблице Clients, а также поле MoneyTaken - типа, взят ли реально кредит клиентом или он в итоге от него отказался. Приложение у нас большое, и это поле используется в куче мест. Теперь разработчикам поступил новый заказ - сделать поддержку векселей. Заказчик сказал, что векселя - это те же кредиты, но с боку бантик. Соответственно, разработчики сделали аналогичную таблицу, и в ней тоже сделали такие же поля ClientId и MoneyTaken, после чего 3 недели в поте лица всей командой делали пользовательский интерфейс, расчеты и отчеты. Через 3 недели выясняется, что на самом деле векселя должны ссылаться не на таблицу Clients, а на другую таблицу - Issuers (соответственно, поле ссылки желательно переименовать), а поля MoneyTaken вообще нет.
Что разработчикам делать в ситуации с традиционной технологией через прямое использование SQL? Задолбаться, потому что поиск по исходному коду выдает не только случаи использования ClientId и MoneyTaken в таблице векселей, но и случаи использования этих полей в таблице кредитов, которых намного больше. Придется либо анализировать все эти случаи, либо по памяти вспоминать, где успели использовать новую таблицу, и менять там. А ведь еще нужно в join-ах и вспомогательных запросах заменять Clients на Issuers и думать, что еще сломается из-за такой замены. В любом случае, тестировать нужно будет много и тщательно, и не только функционал, связанный с векселями, но и старый функционал по кредитам, т.к. не исключено, что по невнимательности поле переименуют/удалят в запросе по кредитам.
А что делать в случае использования Code First/LINQ? Встаем на поле ClientId в классе векселей и вызываем рефакторинг Rename. Поскольку средства рефакторинга в языках со статической типизацией довольно умные, то при этом у нас переименуется только поле в этом классе, кредиты останутся незатронутыми. Нам останется только поменять у нового поля тип с Client на Issuer и удалить MoneyTaken, после чего запустить компиляцию. Компилятор сам выдаст нам ошибки во всех местах, где требуются переделки. Час работы - и при этом можно быть уверенным, что функционал по кредитам на будет затронут в ходе переделки.
Пример 2
Предположим, у нас во всех таблицах есть общие поля (Added, AddedBy, LastChanged, LastChangedBy). В традиционной технологии эти поля дублируются во всех таблицах. Соответственно, если нужно добавить новые поля типа AddedByIPAddress и LastChangedByIPAddress, то придется пройтись по всем таблицам, а также по всем запросам insert и update. Это работа на много часов. В Code First/LINQ у нас все классы будут просто унаследованы от одного базового класса, и функционал по заполнению его полей также будет сконцентрирован в одном методе, поэтому добавление новых полей можно будет сделать один раз.