Создание представления сущности

Question

Можно ли создать представление сущности в платформе сущностей, не создавая представление в DAL?

У меня есть родительская таблица с именем Receipt . Квитанция может быть активной или неактивной. если я реализую IsActive в качестве атрибута Квитанции , существует высокий риск забывания присоединить .Where(r=>r.IsActive) ко всем запросам Linq и высокая стоимость добавления его в предыдущие коды. я пытался унаследовать дочерний элемент DeletedReceipt с условием IsActive = false в модели и добавить условие IsActive = true в квитанцию ​​(родительский). К счастью, бизнес не изменился. проблема в том, что я не могу написать метод Деактивировать, в то время как Квитанция имеет много важных отношений. и я знаю, что это не объектно-ориентированный. Я думаю, что могу справиться с этим с точки зрения. но я не меняю свой DAL для бизнес-метода! регистр " IsActive " играет роль дискриминатора и не может быть обновлен в методе Деактивировать . Одним из способов может быть использование SP, но это означает «DAL, пожалуйста, обращайтесь с моей чертовой бизнес-логикой». есть идеи?

Answer 1

Существует два способа создания вида:

• DefiningQuery - выбор пользовательского SQL в SSDL-части файла EDMX. Вы можете использовать любой SQL для определения новой сущности только для чтения. Проблема в том, что, как только вы используете это, вы больше не сможете использовать обновление из базы данных, потому что оно перезапишет ваши изменения в EDMX (если вы не купите более мощное расширение для дизайнера EF).
• QueryView - пользовательский выбор ESQL в MSL-части файла EDMX, который необходимо выбрать из существующих объектов. Он поддерживает отношения, но только для других представлений запросов.

В обоих случаях созданная сущность является представлением = только для чтения. Вы не можете использовать его для сохранения изменений, если не отобразите операции обновления, вставки и удаления в хранимую процедуру или пользовательский SQL (снова записанный в файле EDMX).

В любом случае то, что вы пытаетесь сделать, приведет к множеству проблем. Вам когда-нибудь нужен доступ к DeletedReceipt в вашем приложении? Если да, нужно ли вам иметь полную логику, как у вас с ActiveReceipt? Если нет, не делай этого.

Проблема в том, что IsActive условие мягкого удаления - это то, что EF обрабатывает не очень хорошо. Вы можете решить эту проблему для своего основного запроса, когда вам не нужно использовать Where(r => r.IsActive), но вы когда-либо использовали готовую загрузку или отложенную загрузку для загрузки связанных квитанций для любых других объектов? Если да, ожидаете ли вы загружать только активные квитанции? Здесь возникает настоящая проблема. Ни стремительная, ни ленивая загрузка не поддерживают фильтрацию, поэтому вы всегда будете загружать как активные, так и удаленные записи. Единственный способ справиться с этим (без выполнения всего вручную) - это условное сопоставление , но условное сопоставление позволяет вам иметь только одну из этих сущностей в вашем приложении, и вам нужна настраиваемая хранимая процедура для мягкого удаления.

"Даль, пожалуйста, разберись с моей чертовой бизнес-логикой"

В качестве дополнительного примечания к этой цитате, если вы не хотите, чтобы DAL обрабатывал какую-либо логику, не ожидайте, что она автоматически выдаст вам только активные квитанции. Это логика и в DAL. Так что если вы действительно имеете в виду, что использование Where(r => r.IsActive) во всех запросах - это то, что вы ищете. Если вы хотите получить некоторую помощь от DAL, она должна содержать некоторую логику, и иногда эта логика будет в SQL.