Какой подход DAL выбрать?

Question

ActiveRecord обычно слишком ограничен.Однако я нахожусь в сложной ситуации с точки зрения взглядов каждого члена команды в отношении использования ORM.В настоящее время мы используем очень простой ActiveRecord с сожалением, которое, как я говорю, написано в основном от руки с некоторым базовым поколением кода.Я хотел бы создать новый DAL для нас, но избегая ограничений ActiveRecord, поэтому DDD больше.Тем не менее, я борюсь против (как старых разработчиков skool, так и меня самого молодого):

Team Lead Developer

• За хранимые процедуры,но не является последовательным ... некоторые просто получают таблицу, например SELECT * FROM Company, а некоторые получают SELECT C. *, O.OtherTableValue FROM C ... (очень расстраивает)
• Не знаетпреимущества некоторых из новейших инструментов ORM
• Не будет ли какой-либо инструмент «слишком ограничительным», и если возникнут проблемы, что вы будете делать?

DBA

• Не нравится динамический SQL
• Не нравится SELECT *

Я не говорю, что вышеизложенное запрещеноЭто более убедительно их в противном случае.Я верю, что мы могли бы значительно повысить эффективность с помощью ORM, но убедить их в обратном можно очень сложно.Если бы я мог представить доказательства в некоторых из этих областей, я мог бы убедить их, даже если бы они выполняли под прикрытием, не зная их изначально, а затем увидев преимущества.

Какой совет вы могли бы дать, чтобы помочь моей ситуации?Я считаю, что многие разработчики сталкиваются с этим и не могут выбрать, какую архитектуру они хотели бы использовать.

Answer 1

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

Во-вторых, я склонен согласиться с вашим администратором по ряду причин.Пока он / она достаточно гибки, чтобы знать, что бывают случаи, когда динамический SQL решит проблему намного лучше.

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

Answer 2

Каковы их возражения против использования ORM?Если они не просто упрямы и упрямы, то если вы знаете, что конкретно они против вас и решают эти проблемы.Как и другие, я думаю, что ваш администратор БД прав.Но если он обеспокоен внедрением SQL из динамического SQL, ORM несколько облегчит эту проблему.Выбор * должен быть основанием для стрельбы.

Я думаю, что вы должны просто использовать что-то, LINQ-to-SQL или дозвуковое или nhibernate на чем-то маленьком.Покажите, что разработка может быть быстрее и чище с использованием ORM.

Answer 3

Ведущий разработчик должен слушать администратора баз данных.«ВЫБРАТЬ *» - это плохо.И из пулевых точек о ведущем разработчике это звучит так, будто у вас знакомая тяжелая битва.Иногда путь наименьшего сопротивления в этой ситуации заключается во внедрении чего-либо с использованием ORM (например, NHibernate) и планировании какой-либо демонстрации для команды.

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