Вещи, которые мы хотим сделать «потом»

[@SeoTron]

Фу, желтая джойреакторовская полоска… Лучше бы убрать… Завтра…

[@xakpc]

По поводу базы данных не все так страшно. Просто до многого самому допереть не просто, есть отличная книга Фулера Database Refactoring. Там пошагово объяснено что, как и зачем

[@marshinov]

Тут такая незадача получается. Если слой БД адеватно отделен и не «пролезает» в остальные слои, то это скорее всего DDD. Если на уровне кода такое проектирование, то БД вероятнее всего тоже сделана на совесть и неожиданностей не происходит. А вот если неожиданности в БД были, к гадалке не ходи, они пролезают выше. Пример из личного опыта. Чуваки использовали генератор БД по сущностям из .edmx-файла. Я конечно вообще не очень понимаю людей, использующих .edmx, но бог с ними. Если в цепочке классов существует наследование, EF отображает это как 2 таблицы с отношением 1 к 1. Это уродство так и осталось в приложении, потому что завязалось на linq-запросы в DAL'е.

[@andreycha]

Вы предпочитаете не хранить в базе наследованные сущности?

[@marshinov]

не понял вопроса)

[@andreycha]

Вы написали:

Если в цепочке классов существует наследование, EF отображает это как 2 таблицы с отношением 1 к 1. Это уродство

Что плохого в отображении наследования в виде двух таблиц со связью 1:1? Это одна из распространенных стратегий отображения наследования в реляционную БД.

[@marshinov]

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

[@BloodJohn]

Отличная статья. Спасибо.

[@AdrenaLeen]

А какую систему управления проектом используете?

[@marshinov]

Разные