LINQ-to-SQL поддерживает использование с UDF, если вы это имеете в виду. Просто перетащите UDF на поверхность дизайнера, и все готово. Это создает метод сопоставления для контекста данных, помеченный [Function(..., IsComposable=true)]
или аналогичный, сообщающий LINQ-to-SQL, что он может использовать это в запросах (обратите внимание, что EF не поддерживает это использование).
Затем вы будете использовать его в своем запросе как:
var qry = from cust in ctx.Custs
select new {Id = cust.Id, Value = ctx.GetTotalValue(cust.Id)};
, который станет TSQL примерно таким:
SELECT t1.Id, dbo.MyUdf(t1.Id)
FROM CUSTOMER t1
(или около того).
Тот факт, что это компоновка, означает, что вы можете использовать значение в запросах - например, в Where()
/ WHERE
- и таким образом уменьшить объем данных, возвращаемых с сервера (хотя, очевидно, UDF все равно потребуется быть исполненным каким-либо образом).
Вот аналогичный пример , показывающий псевдо-UDF при использовании в контексте данных, иллюстрирующий, что версия метода на C # не используется.
На самом деле, в настоящее время я смотрю на такие UDF, чтобы обеспечить возможность компоновки данных "вне модели" - т.е. определенной части системы требуется доступ к некоторым данным (которые находятся в той же базе данных), что и на самом деле не часть той же модели, но которую я хочу JOIN
интересными способами. У меня также есть существующие SP для этой цели ... поэтому я смотрю на портирование этих SP на табличные UDF, которые обеспечивают уровень контракта / абстракции, окружающий данные вне модели. Так как это не является частью моей модели, я могу получить ее только через UDF - но у меня сохраняется возможность составить это с моей обычной моделью.