#entity-framework #clean-architecture
Вопрос:
В моем контексте бд в инфраструктурном проекте есть много таблиц, которые меня не интересуют в моем приложении. Другим приложениям они могут понадобиться, но моему приложению-нет. Если я удалю их из своего доменного проекта, сборка завершится неудачно. Тот же вопрос касается неиспользуемых свойств. Пожалуйста, будь со мной помягче… Я здесь новичок 🙂
Комментарии:
1. Можете ли вы добавить пример того, что вы пробовали? При работе с существующими базами данных, где вам требуется частичное представление, я настоятельно рекомендую использовать ручную настройку либо с помощью OnModelCreating, либо лучше,
EntityTypeConfigurationчтобы отобразить желаемую сущность в БД, а не пытаться использовать конструктор/EDMX. Очевидно, что если вы вставляете строки, вам необходимо убедиться, что все ненулевые свойства сопоставлены.2. Забудьте о вставках, у меня есть DbContext с первым кодом, который поддерживает несколько различных приложений с чистой архитектурой. Не все из этих приложений нуждаются в каждой таблице, определенной в контексте. Поэтому каждое приложение ДОЛЖНО иметь класс сущности для всех таблиц, даже для тех, которые его не интересуют. В противном случае сборка завершится неудачно… не уверен, что пример здесь что-то добавляет, поскольку я был ясен как день. Может быть, это инженерный вопрос? Если так, то извините.
3. Тогда в чем именно заключается ваш вопрос? Как вы можете определить 1 DbContext для нескольких приложений, но не обременять эти приложения знаниями о каждой таблице и свойстве?? Просто, не используйте 1 отдельный DbContext… Определение специально созданных DbContexts и определений сущностей очень просто. Меньшие DbContexts инициализируются быстрее, и ваш доменный интерфейс должен соответствовать строго таблицам и столбцам, необходимым приложению, а не путать будущую разработку с множеством ненужных несвязанных пух. Даже в рамках отдельных крупных приложений я буду определять несколько ограниченных DbContexts.