Вот Fluent API же нормально сделан - всё типизировано, заделегатено, залямбдено. А миграции как будто из 90-х годов.

hVosttAlexey2112Вот Fluent API же нормально сделан - всё типизировано, заделегатено, залямбдено. А миграции как будто из 90-х годов.

Ну так в этом и прелесть, выбирай, что тебе лично удобно. Удобен флюент? Флаг в руки ))
Флюент многословен. Несколько символов атрибута в модели против нескольких строк во флюэнте. Со флюэнтом количество текста, который надо напечатать, увеличивается раз так в пять-десять.

Нет, я не хочу флюэнт. Я хочу типизированный выбор с помощью IntelliSence в миграциях. Например, сейчас так




А хочу типа такого

И да, я не хочу ничего самому писать - переписывать половину EF CF. Почему они сразу не написали всё через рефлексию и выражения с лямбдами, а сделали тупой и топорный АПИ через строки, как в 90-х или какой-нибудь Джаве, прости господи?

petalvikhVosttТебе помочь, разобраться, почему тут нельзя использовать типизированные лямбда-выражения? Ни при каких обстоятельствах.

Ни. При. Каких. ВОобще. Никак. Это невозможно. Хоть призови весь Гугл, Фейсбук и Эппл на помощь. Призови Шойгу и древних индийских шаманов с галюциногенными грибами.
Гм, как сказать... Я призову трёх польских студентов и их язык Nemerle. Ну или любой язык с развитым метапрограммированием.
Макрос может на этапе компиляции слазить в БД и проверить соответствие типов. (Конечно, в рантайме код всё равно может упасть, если схема БД окажется другая). Пусть не совсем то, но близко.
Какие лазания в БД в CF? У нас код главнее. У нас БД - это модель на сишарпе. Куда и зачем лазать? Что, нельзя по классам полазать и дать возможность их свойства указывать не строками, а лямбдами?

Всё, ребята, приплыли. Щас другие времена настают. Кончились времена исчадий ада - этих ваших DBA, которые, дай им волю, вообще бы все приложения прямо в СУБД и писали на своих чёртовых хранимках. Щас СУБД - робкая обслуга сишарпобояр. Кто там лезет своими грязными похотливыми ручонками в мою БД через свою сраную админку? - Убью нафиг! Теперь только через код и только для благородных донов-программеров.

hVosttПомочь разобраться, ну почему же строки, а не рефлексия?
Да. Я чёта не вдупляю в упор.

И чего ты смайлов понаставил? Какой-то подвох?

hVosttУ меня должен храниться код всех миграций, в разные моменты времени я должен ссылаться на то, чего ещё не существует, или то, чего уже не существует.
Ты прав... Но ты же понимаешь, что я не могу этого вот так просто признать. Я должен обязательно что-то сказать против, обозвать, в конце концов в МСУ-стайле, ещё что-нибудь. Да и традиции требуют сопротивляться до последнего, до полного маразма. Сейчас, что-нибудь придумаю... А, вот - какого хрена вся история сущностей не хранится в строго типизированном виде? Ну, типа системы контроля версий - все когда-либо созданные сущности хранятся в ней, но мапятся только актуальные. Но при этом сохраняется возмодность указать даже лямбдами на то, что уже не существует в БД, но по-прежнему есть в коде.

Насчёт "чего ещё не существует". Так миграции по добавлению новой сущности или свойство уже существующей сущности пищутся после такого добавления. Т. е. рефлексией или выражением по этому уже можно пройтись и лямбдой это дело указать.

hVosttМиграции не программируются, они по большей части генерируются

Что-то в этом есть... Но править их руками-то позволено всё равно. Ну и плюс, как тут говорили, генерируются только элементарные меграции, а посложнее - уже ручками. Тут-то рефакторинг и прочий треш и всплывают. Вот накопилась у тебя сотня миграций, а потом ты решил поменять название свойства, таблицы, ещё что-то. А у тебя всё захардкодено строками. Полнотекстовый поиск и замена - чреват ошибками из-за ложного срабатывания (где-то названия могут отличаться только суффиксами или префиксами). Т. е. никакой автозамены по всем файлам - только по одной замене за раз - не сильно производительнее, чем вручную искать и заменять. Делать сложные регулярки для таких вещей? - Чёта я взоржал с таких технологий в век рефакторинга на основе строго типизированного анализа кода.

Alexey2112Потому что у меня есть другое свойство в другой модели

[Required]
public string Name { get; set; }

автосгенеренная миграция для неё получилась такая

Name = c.String(nullable: false),

а в БД это выглядит так

Name
nvarchar(MAX)
allow nulls:нет галочки
Не, тут всё же какая-то другая инопланетная логика. Я НЕ использовал атрибут Required, а миграция всё равно сделалась с nullable:false. Что за фигня вообще тут творится с этим CF?!

Вот модель




вот миграция




Всё же, там, похоже, и на основе Required, и на основе самого типа свойства основывается - nullable оно или нет. Т. е. атрибутом Required можно сделать не nullable всякие по природе nullable-типы (типа ссылочных типов). А для всяких чисел, которые по определению не nullable, можно сделать nullable с помощью типа Nullable<T> (int?, double? и т. д.). Вот теперь правильно?

Кстати, а кто как миграции содержит? Ну будет у вас сотня миграций - а как вы их назовёте? Я пока так делаю

201506170934203_TestTable_AddCommentaryProperty

Это нормально, или есть способ лучше? А то чувствую, что папка Migrations скоро будет состоять из гиганстского списка миграций, которые упорядочены по времени и только.

Или штука в том, что миграций В ПРИНЦИПЕ не должно быть сильно много, поэтому вроде как предполагается, что и проблем по управлению миграциями и их хранению и упорядочиванию не должно возникать?