Предложить дизайн доступа к данным для Entity Framework (хранимая процедура меньше)

Question

Планируется использовать Entity Framework для доступа к данным.Мы стоим перед дилеммой, решая, использовать хранимые процедуры или нет.

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

Есть ли какой-либо удар по производительности, если я пишу объединения, бизнес-логику на уровне доступа к данным?Это так же хорошо, как хранимые процедуры?Пожалуйста, предоставьте свои рекомендации.

С уважением, Рамана Акула. ​​

Answer 1

Недостатки SP:

1. Код SP "исправлен" - например, у вас нет гибкости LINQ здесь.Для этого требуется дополнительный уровень синхронизации.
2. В большинстве случаев должен быть написан специалистом.Исторически почти все разработчики на C # не очень хороши в этом.
3. Несмотря на то, что вы прикладываете дополнительные усилия для поддержки SP, вы не получаете значительного улучшения производительности
4. Даже если у вас нет намерения, SPбудет содержать некоторую часть кода бизнес-логики.
5. Если вы потеряете некоторый контроль над обслуживанием SP (или добавите преждевременную оптимизацию в DAL), вам понадобится все больше и больше SP: getXbyY, getXbyZ, getSomeFieldByX, geAnotherFieldsByX и т. д. и т. д.

Так что мое мнение заключается в том, чтобы по возможности избегать SP.Если вы считаете, что он вам нужен, это может указывать на неверный дизайн структуры данных / хранилища.