Таким образом, у меня есть требование клиента использовать только хранимые процедуры для всех операций с базой данных. Я создал хранимые процедуры CRUD для каждой из моих таблиц, а затем создал мои модели Entity.Отображение хранимых процедур объекта?
Так что я легко вижу, как сопоставить мои вставки, обновления и удаления хранимых процедур с моей сущностью (например, клиент), но, похоже, нет способа сопоставить мой выбор? Это простой простой выбор, он должен просто вернуть список моих объектов-клиентов, поэтому он напрямую сопоставляется с моим типом Entity, он не является обычным. Кажется, единственный способ сделать это - импортировать функцию и сопоставить ее.
Итак, почему нет возможности сопоставить выбор напрямую? Для меня были бы огромные преимущества!
Возможно, моя хранимая процедура не подходит?
У кого-нибудь есть идеи?
Это обходной путь, который я использую. Но на самом деле это не решает проблему - например, с классом DomainService, он хочет использовать свойство Customer для получения свойств - мне нужно вручную изменить мою службу, чтобы использовать мою импортированную функцию, что плохо, если мне нужно восстановить мои оказание услуг. Вставка обновления и удаления может быть сопоставлена так, что на уровне сущности они используются. Но вы не можете сделать это для выбора. – Nicros
На самом деле это не так много «обходного пути», кажется логически законным. Для выборок, как я упоминал («привязать тип возврата к модели сущности»), хранимые процедуры могут быть сопоставлены непосредственно с типом сущности, а не с типом, специфичным для функции хранимой процедуры. Итак, в моем примере MyStoredProcedure() возвращает экземпляр MyEntity, а не что-то еще. По умолчанию это что-то еще, вам нужно вручную сопоставить вывод с MyEntity с уровня импортированного интерфейса, это противоположный конец назначения sproc для объекта. Та же разница действительно, просто другое место. –
Извините, если я не был достаточно полезен, но чтобы ответить на ваш первоначальный вопрос, не так много можно сделать, если lib все еще имеет это ограничение. Сейчас я все еще расстроен тем, что INSERT через SPROC не привязывает столбец IDENTITY к выходному параметру. Для того, чтобы быть предположительно «корпоративным классом», EF4 по-прежнему довольно жалкий, не благодаря этому и обходным решениям, которые необходимо выполнить. –