Alexey2112Не, я понимаю, что fluent API крут, но что, предлагается всё-всё кастомное запихнуть в один метод OnModelCreating, который грозится разрастись до тысяч строк?

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

Alexey2112Т. е. такое ощущение, что сначала CF был с ограничениями, покрывающими не все кейсы создания БД, по сравнению с моделированием в визуальном редакторе или с SQL, а потом стал лучше. Так вот, с какой версии EF этот CF стал достаточно развитым, чтобы не натыкаться на ограничения через раз?

С поисками серебряной пилюли и священного Грааля, покрывающего абсолютно все мыслимые и немыслимые кейсы и возможности применения, это не к области инженерии, а куда-нибудь к мистикам или любителям поп... потрепаться и почесать языком попусту. Со своими весьма конкретными задачами CF справляется с лихвой. Если хочется пиджак с переподвиподвертом, это не к CF, пиши свой расовый фреймворк для своих подвыподвертов, никто же не запрещает?

Alexey2112Простой пример - отношение one-to-one (ну, пусть будет one-to-one or zero). Конвенций - нет. Атрибуты - захардкоденные строки с именами свойств. Выход? - Fluent API .

Атрибутами это можно сделать. Соглашениями это можно сделать. Захардкоженные строки в атрибутах? Ну а как ты ещё имена проперти передашь, с этими претензиями уже к разработчикам C#/.NET, чего это они такие сякие, не разрешили нам экспрешены прямо в атрибутах? Ууух, нехорошие. Приходится обходится мерзкими хоббитцами строками.

Если тебе понадобилось что-то совсем хитрое, но хочется без блюента, то кастомые атрибуты, кастомные соглашения.

Alexey2112Я критикую EF не потому, что я обижен на весь мир и вообще красноглазый ненавистник виндов , а потому, что надеюсь встретить встречный комментарий, опровергающий мои "наезды". Наверное, лучше не наездами, а более конкретными вопросами. Но наездами "прикольнее" и веселее. )))

Ну дак ты давай уместную критику. Думаешь EF не за что покритиковать? Ещё как есть. Но твои "наезды", пока критикой назвать нельзя.

"Мне не нравится флюент"
"Мне не нравятся строки"
...

Это не критика, бро ))

Alexey2112Как? Покажи, пожалуйста. Я имею ввиду соглашениями. Атрибутами я и сам выше показал, как.

Соглашение + атрибут, извиняюсь что не уточнил сразу. Суть в том, что ты можешь определить какой-нибудь свой универсальный атрибут, без указание свойства с помощью строки, а в соглашении поймать его и обработать.

Вот пример кастомного атрибута:

https://msdn.microsoft.com/en-us/data/jj819164#attributes

Писать код конкретного примера не буду, но думаю ты легко сам догадаешься, как сделать свой атрибут типа [OneToOneRelation].

Alexey2112ОК, возможно, можно передать в кастомный атрибут параметр типа bool IsOneToOne. Ну, переписать логику маппинга, ладно. Извернувшись, допустим, получится... Но ты-то сам как решаешь эту проблему (one-to-one)? Довольствуешься строками в атрибутах? Всё кастомное пихаешь в OnModelCreating через Fluent API? Ещё что-то?

Что можно, я решаю стандартными способами, для таких случаев атрибуты со строковыми значениями, которые меня ничуть не пугают и к проблемам не приводило, так как изменения модели довольно редки, к этим изменениям повышенное внимание, не понимаю в чём проблема со строковыми атрибутами? Может ты вообще строками не пользуешься? Да, я люблю типизацию, но всему своё место.

Прямых конфигураций избегаю, как конфигураций-классов, так и события в DbContext. Всё решалось пока.

Alexey2112Вот прям щас у меня проблемы нет - мне надо небольшую БД сделать и запихать в OnModelCreating с десяток таких вот 1-1..0 мне не трудно. Но меня интересует, как люди по-взрослому работают - пишут кастомный атрибуты? Может, есть стандартный воркэраунд, который я не знаю? - Меня вот это интересует - не писать кастомное, пока точно не получу информацию, что "из коробки так сделать нельзя" .

Ещё раз говорю, прямые конфигурации -- небольшое, но мелкопакостное зло. Мне удаётся всё покрыть соглашениями, по большей части стандартными, и кастомными, где нехватает. Я не пишу на каждую таблицу OnModelCreating. Если создаётся прецендент, расширяется модель соглашений, даже если она будет использоваться только для одной таблицы, пока.

А из коробки много чего нельзя делать, но можно приравнять. Тыжпрограммист, или где?

Alexey2112для связи 1-1 есть ещё вариант через complex type, но там лимитации экзистируются.

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

Alexey2112,

Если настроек много, и они расширяемые, то наверное следует подумать о другой модели хранения, нормализовать, например, вот так:

TABLE Properties (Id, Name, Group, Type)

TABLE Values (Id, UserId, PropertyId, Value)

Если разброс диапазонов значений большой, от чисел до безразмерного текста, для Values можно сделать иерархию в одной таблице для хранения значений разного типа в разных полях, это в EF сделать легко.

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

Самый частый кейс, где бы я применял 1:1, это вынос крупных данных (например, блобов) в отдельные таблицы, чтобы они материализовались только по запросу и для возможности вынести их, допустим, в отдельный tablespace.

Алексей К Тут

message: сообщение
message_task: сообщение-задача
message_comments: сообщение-комментарий

Предлагай альтернативу.

На мой взгляд, тупо. Можно воспользоваться наследованием и хранить всё в одной таблице, EF такое предлагает нативно. Или воспользоваться наследованием, если религия не позволяет в одной, хранить в нескольких таблицах. EF предлагает такое нативно. Вопросы? ))

Алексей КEAV - зло!

Какой-то нелепый наброс. Зло это бездумное, фанатичное, следование какой-то одной идеологии. В данном случае EAV это то, что доктор прописал, так как гибко и не создаёт потенциальных таблиц с овер 100 полями. И не надо мне рассказывать только сказочки и глупые нелепости о том, как некто в компании Х работал там с 10000000000 таблицами с 1000000000 полями. Если ума нет, считай калека.

Алексей КИ какие несчастья нам грозят из-за этого "ужаса"?

Ну как же, "строки -- зло!" )))))))

Alexey2112Рефакторинг. Наделал ты сто таблиц, наделал отображений, и тут надо поменять пару названий, которые встречаются 50 раз. Полнотекстовый поиск, вместо контекстного рефакторинга?

Даю подсказку. Именованные константы!

Alexey2112Так, чтоли?

TABLE Values (Id, UserId, PropertyId, ValueInt, ValueDouble, ValueByteArray, ValueBool, ValueString, etc.)

Ты только скажи, если я в строке запишу только в одно поле из всех Value..., то другие будут занимать место в БД, или нет?

Нет, они все будут храниться как NULLABLE и места занимать не будут, не волнуйся. Просто не переживай об этом.

Alexey2112Ещё раз, ребята. Нет какого-то определённого правила, как лучше моделить в БД композицию классов (т. е. когда поля класса могут иметь тип другого класса)? Т. е. нельзя сказать, что композиция - только через EAV, или через 1-1..0, или только через complex types? Каждый раз подбирается по ситуации?

Каждый раз, для каждой отдельной задачи, в зависимости от требований, области применения и способу использования, решения могут в корне друг от друга отличаться. Вплоть даже до смены SQL на noSQL