Entity Framework - Сделать сгенерированные подписи процедур и функций, не зависящих от EF

Question

это Entity Framework 6.1.3.

Я хочу, чтобы иметь возможность извлекать interface для моих хранимых процедур. И я хочу, чтобы этот интерфейс не имел никакой зависимости от сборки EntityFramwork.dll, поэтому я могу абстрактно описать его на клиентских слоях, поэтому у них нет поддержки/ссылки/зависимости для Entity Framework.

Проблема в том, что EF ставит классы, подобные ObjectResult, и ObjectParameter в созданную подпись метода. И эти классы определены в сборке EntityFramework.dll, поэтому он вводит зависимость на извлеченном интерфейсе, чего я хочу избежать.

Я решил ObjectResult проблему таким образом: я редактировал файл MyEntities.Context.tt, и внутри метода public string FunctionMethod(EdmFunction edmFunction, string modelNamespace, bool includeMergeOption) я нашел строку, которая была первоначально это:

returnType == null ? "int" : "ObjectResult<" + _typeMapper.GetTypeName(returnType, modelNamespace) + ">", 

Так что я изменил его на это:

returnType == null ? "int" : "System.Collections.Generic.IEnumerable<" + _typeMapper.GetTypeName(returnType, modelNamespace) + ">", 

Таким образом, тип возврата для сгенерированных процедур больше не ObjectResult<>, но IEnumerable<>, что отлично.

Но я не мог решить проблему для корпусов ObjectParameter. Они генерируются EF, когда у нас есть параметр Output (или параметр InOut). Я хотел бы заменить созданный по умолчанию ObjectParameter myParam в сигнатуре метода для ref int myParam, например. И храните ObjectParameter в коде метода, а не в его подписи. Поэтому каждый метод должен создавать внутри ObjectParameter и помещать возвращаемое значение в параметры метода out/ref.

Я старался, но не смог найти способ редактировать MyEntities.Context.tt таким образом. Возможно, кто-то, кто лучше знает T4 и EF, может представить простое решение ...

Большое спасибо!

Answer 1

Решение состоит в том, чтобы определить интерфейс таким образом, который подходит вашим клиентам больше всего, и иметь реализацию, которая адаптируется к коду, который требует EF.

Другими словами, не пытайтесь сжать круглый штырь в квадратном отверстии, отредактировав свой шаблон T4 или злоупотребляя EF. Вместо этого создайте независимую реализацию, которая обертывает EF или делегирует вызов EF и преобразует возвращенные данные таким образом, который подходит интерфейсу. Эта реализация, вероятно, будет содержать всего несколько строк кода, поскольку она должна иметь дело только с преобразованием -или- иначе, поскольку вы имеете дело с хранимой процедурой, полностью удалите EF из уравнения и вызовите SP непосредственно через ADO. СЕТЬ. Моделирование этого SP через EF может не иметь особого смысла.