Использование методов расширения в архитектуре

Question

Есть ли проблемы с производительностью, памятью, безопасностью и т.д. c. при использовании методов расширения?

и я хочу широко использовать методы расширения в своей архитектуре,

создайте уровень функций (в F #, который работает с данными), который будет использоваться основным приложением слой (в C#), что методы расширения F # будут вызываться в экземплярах dbcontext, таких как context.doSomething();, и, кстати, не создавать экземпляры служб (классов), когда вы хотите их использовать, вместо этого используя их как методы расширения

это имеет значение?

Answer 1

Метод расширения

var newString = myString.DoSomething();

- это просто синтаксис c сахар вместо

var myString = StringHelper.DoSomething(myString);

Поэтому относитесь к методам расширения с такими же соображениями, как и к любому другому методу static. Производительность, безопасность и использование памяти должны быть идентичными.

Answer 2

Есть ли проблемы с

Посмотрим ....

производительность

Нет, это синтаксис c сахар для вызова метода c stati. Без разницы.

память

Я сказал вызов метода stati c с указателем this. Без разницы.

security

Stati c вызов метода с указателем this. Нет разницы. Применяется стандартная безопасность.

СКАЗАНО ...

et c

Есть несколько возможных проблем с методами расширения.

Во-первых, вы обязательно должны перегрузить свой DbContext сотнями методов расширения. Это теряет возможность фактически создавать своего рода логическую группировку. Люди запутаются и, возможно, даже запутаются, откуда берется конкретный c метод.

Во-вторых, вы успешно торпедируете использование наследования и внедрения зависимостей. Методы расширения - это, по сути, c методы, поэтому они не могут быть абстрактными и перезаписанными, а в экземпляре нет конструктора для вызова внедрения зависимостей.

В качестве основы архитектуры я был бы очень осторожен возможно удачно торпедировать все, что составляет хорошую архитектуру. Очевидно, это зависит от конкретного варианта использования.