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

Где тут бардак? У меня есть Message и есть UserMessage, GroupMessage, ProjectMessage. Почему это должны быть совершенно разные таблицы, если суть у них одна, основной набор данных один, базовая логика одинаковая, основные контролы/шаблоны UI одни? С какого перепугу? Или предлагаешь это всё нагенерить? С логикой у меня всё в порядке, а у тебя? ))Ты строишь систему от ООП модели, я строю от реляционной модели в БД, вот и вся разница. Мне удобнее так, тебе удобнее по другому. Мы оба правы, доказывать тут что-то глупо, оба подхода имеют право на жизнь.
hVosttАлексей КОдин класс-одна таблица - это мой выбор и не тебе его осуждать. Но можешь не согласиться, твоё право.

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

hVosttАлексей КЧто не так?

Бардак, разброд и шатания, усложнение без видимых причин, кроме разве что небольшой степени упоротости )Спасибо за ценную информацию, которая наверняка пригодится читателям форума!

hVosttАлексей КБД важнее кода.

А крокодил зеленее ширины слона. Рубль слаще бутерброда.

Глупые сравнения меня не интересуют, и код и БД одинаково важны, т.к. юзер останется с носом, что без одного, что без другого. Или дизайнер и БД это для тебя одно и тоже? )))В работающей информационной системе обычно код модифицировать проще, чем структуру БД. Обычно код меняется чаще структуры БД. Утерянный код восстановить можно, утерянную БД восстановить невозможно.

Вероятно, ты работаешь не с информационными системами, отсюда у тебя другие взгляды на ситуацию.

hVosttАлексей КЕсли нет чёткого понимания, какой будет план выполнения у сгенерированного SQL - это путь в никуда.

И как же ты живёшь с DbContext? На все LINQ запросы планы посмотрел?На все, имеющие проблемную статистику выполнения.

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

Где тут бардак? У меня есть Message и есть UserMessage, GroupMessage, ProjectMessage. Почему это должны быть совершенно разные таблицы, если суть у них одна, основной набор данных один, базовая логика одинаковая, основные контролы/шаблоны UI одни? С какого перепугу? Или предлагаешь это всё нагенерить? С логикой у меня всё в порядке, а у тебя? ))Основной набор данных один, но есть и специфичный набор данных, разный для каждого класса. Теперь включаем логику, с которой у тебя всё в порядке. :-)

Alexey2112Алексей Кпропущено...
И изменить модель данных в MSSQL с реляционной на какую-нибудь другую?
А реляционная не эмулируется на .NET? Вроде, даже с избытком. В крайнем случае можно расширение языка или библиотечку ввести. Главное, что вообще нафиг убрать всё это многообразие языков, которые все по сути делают одно и то же. Приходишь на работу - надо знать туеву кучу всякой дряни, помимо C#. А ты такой им - я знаю C#, EF Code First, WiX#, SharpDX, LINQ вместо SQL и т. д. - Нет, вы нам не подходите.

Кстати, LINQ вместо SQL - тоже нужно в массы. Тогда и маппинги с ОРМами не понадобятся - всё будет нативно сразу.

Ну есть же простейший пример в реляционной модели - *-*. Моделирование этого через промежуточную таблицу - костыль. А в ООП - легко и непринуждённо через коллекции. А теперь костыли в обратную сторону (если найдёте)?Ну можно же сериализовать объекты в XML и хранить в отдельных файлах. Зачем нам вообще MSSQL?

Alexey2112Алексей Кпропущено...
Ну можно же сериализовать объекты в XML и хранить в отдельных файлах. Зачем нам вообще MSSQL?
А кто его знает, как MSSQL хранит объекты у себя внутри. Может, и в XML иногда.Мне, по большому счёту, всё равно, как он там хранит данные. Мне важны его возможности по их обработке, потому что очевидно, что все данные из БД на клиента я забрать не могу из-за их количества.

hVosttАлексей КТы строишь систему от ООП модели, я строю от реляционной модели в БД, вот и вся разница. Мне удобнее так, тебе удобнее по другому. Мы оба правы, доказывать тут что-то глупо, оба подхода имеют право на жизнь.

Зачем ты ООП приплёл? У тебя что, в программном коде нет ООП, там эээ... мм... реляционная модель? Шта? ))))))))

Реляционная модель, это модель хранения данных, а ООП это вообще из мира программирования, там даже слово такое есть "программирование". Ты большой любитель крокодилов с ложками сравнивать.Я тебе говорю о методах проектирования, об способах описании структуры данных, об учёте физических особенностей СУБД на этапе проектирования. Причём тут программа? UML vs ER при проектировании, может так будет понятнее.

hVosttАлексей КВ работающей информационной системе обычно код модифицировать проще, чем структуру БД. Обычно код меняется чаще структуры БД. Утерянный код восстановить можно, утерянную БД восстановить невозможно.

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

hVosttАлексей КВероятно, ты работаешь не с информационными системами, отсюда у тебя другие взгляды на ситуацию.

Я дружу с логикой.
А ты занимаешься сравнением жопы с пальцем и радуешься своим выводам как ребёнок )))Я хочу пользуясь случаем порассуждать на эту тему, пусть я в чём-то не прав, ну и что? Не будь занудой. :-)

Alexey2112И эти люди собираются лететь на Марс . Да вы же поубиваете друг друга в первую же неделю, если вам пива не давать.Что значит пива не давать?! И водку тоже?!
Alexey2112Интересно, что хоть и используешь code first, а всё равно на листочке и в голове рисуешь эти квадратики. Кляты любители дизигнеров! Ещё долго из головы эту нетрушную дурь выветривать.Не надо ничего выветривать. "Новое - забытое старое" (ц)

Они сейчас побегают со своим CF, наиграются и потом скажут, что таки лучше БД делать как раньше в дизайнере, а DbContext генерировать по готовой БД.

И какое их вообще дело до наших методов проектирования? Их дело выдать на гора качественный, гибкий и расширяемый LINQ ORM. А как его мы будем применять, это уже не их не касается!

hVosttAlexey2112Мде... Ну ладно, уговорили меня в соседней теме создать модель данных помимо модели предметной области, хотя сущности что там, что там почти один в один совпадают. Но что делать с enum'ами и прочими совпадающими данными? Ну перечисления-то просто абсолютно одинаковые в обеих моделях. Вывод? - Как-то расшарить энумы между моделями. Как? Выносить энумы в отдельную сборку? Ссылаться в сборке модели данных на сборку модели предметной области? Или таки дублировать энумы в обехи сборках копипастом (ну это точно не дело)?

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

Ну не все себе могут позволить, или считают необходимым, иметь специальных людей, занимающихся только моделированием предметной области. Это может быть тот же программист, рисующий сразу структуру БД со слов технолога, ничего не понимающего в информационных системах.

Проснись, пора уже. :-)

hVosttИспользуя такие штуки, как EA, можно всё это добро тупо сгенерить из модели, а дальше ручками. Если хочется совсем полной автоматизации, можно создать цепочки типа модель-база, модель-код, и как-то всё это синхронизировать, но тогда есть опасность потерять контекст и смысл, для чего тебя наняли и увлечься генераторами... Что и было предложено.

Alexey2112С энумами пока решил - добавить ссыль на сборку с моделью предметной области.Дались тебе эти энумы. Ну ставь рядом с "магическим числом" комментарий, где по коду не понятно, из какого классификатора код. Обычно всё понятно, даже комментарии не требуются.

зы: энумы тоже можно сгенерировать по БД. Благо T4 Text Template теперь в комплекте.

Alexey2112Алексей Кзы: энумы тоже можно сгенерировать по БД. Благо T4 Text Template теперь в комплекте.
Ты опять за своё? У нас тут CF!Ну и что теперь, выгоните меня? :-)
Alexey2112Кстати, не смотрел ещё, как CF генерит таблицы для энумов. Если в виде таблицы-справочника, то ОК.Вероятно, никак.