Как Entity Programming меняет наше представление о базах данных?

Question

Мне интересно, как переход от реляционного, табличного дизайна к объектно-ориентированному, объектно-ориентированному дизайну влияет на мышление разработчиков, пишущих следующую волну приложений.

Учитывая природу дискуссии, которая идет вокруг Entity Framework и Linq to SQL , преждевременно ли думать о проектировании, управляемом объектами?

Создаем ли мы новое поколение разработчиков, которые не будут понимать основные принципы проектирования и разработки реляционных баз данных, потому что они будут защищены от них такими инструментами, как Entity Framework? Действительно ли Entity Framework достаточно умен, чтобы принимать такие дизайнерские решения за них?

Answer 1

Хммм, сложный вопрос ответить imho.

Я не думаю, что такие инструменты, как «структура сущностей», приведут к появлению поколения разработчиков, которые не понимают принципов проектирования реляционных баз данных. Во-первых, объектно-ориентированное проектирование уже давно, и люди искали решения, позволяющие преодолеть разрыв между ОО и СУБД.

Я не вижу «объектно-ориентированный дизайн», как вы его называете (я бы скорее назвал его «доменно-ориентированный дизайн»), замените реляционный дизайн БД. Фактически, для меня эти две вещи будут продолжать жить рядом друг с другом, так как обе технологии - ИМХО - лучшее решение проблемы, которую они пытаются решить: - ОО является идеальным способом для моделирования данных + поведения - реляционная модель является идеальным способом эффективного хранения данных и выполнения запросов к ним.

Если вы хотите добиться успеха в создании приложения в доменной манере (используя O / R mapper, такой как NHibernate или Entity Framework), все равно необходимо, чтобы вы - разработчик - имели базовые знания и знания о как работает реляционная модель. Фактически, вы все еще общаетесь с реляционной базой данных, хотя и через O / R Mapper. Если вы хотите иметь хорошо работающее приложение, вам нужно знать, например, что реляционная база данных настроена на основе; что не стоит выполнять запрос SELECT n + 1 и т. д.

Фактически, я использую O / R mapper (NHibernate) в течение одного года (профессионально), и я играл с ним в течение нескольких лет, но я все еще предпочитаю создавать свою модель реляционных данных вручную , Я не генерирую свою модель БД через свой O / R mapper через классы, которые я написал, так как я хотел бы быть под контролем.

Итак, короткий ответ: я думаю, что разработчику все равно потребуется понимание реляционной модели, если он хочет добиться успеха, используя инструмент O / R.

Answer 2

Хороший вопрос.

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

Что касается вашего второго пункта.

Мы воспитываем новое поколение разработчики, которые не будут понимать основные принципы реляционных проектирование и разработка базы данных, потому что они будут защищены от их такими инструментами, как сущность Framework?

Было бы так плохо заключать в капсулу одну из самых болезненных частей современной разработки программного обеспечения, от повседневного разработчика? Я вижу это в том же свете, что и управление памятью, когда языки высшего порядка начали отвлекать разработчиков от c ++. Значит ли это, что вы можете забыть об управлении памятью? Нет, совсем нет, но вам не нужно сосредотачиваться на этом почти на том же уровне интенсивности, что и раньше. Оставляя больше мозговых циклов, чтобы сосредоточиться на проблемах бизнеса вашего программного обеспечения. Если это возможно, я с нетерпением жду того дня, когда смогу сделать то же самое с моей моделью постоянства.