Поддерживает ли текущее доказательство принятие контекстных по сравнению с каноническими моделями данных?

9

«Каноническая» идея широко распространена в программном обеспечении; паттерны, такие как Canonical Model , Canonical Schema , Canonical Data Model и т. д., как представляется, снова и снова появляются в процессе разработки.

Как и многие разработчики, я часто некритически следовал общепринятому мнению, что вам нужна каноническая модель, иначе вы столкнетесь с комбинаторным взрывом картостроителей и переводчиков. Или , по крайней мере, я использовал, чтобы сделать это , пока пару лет назад , когда я впервые прочитал несколько-позорный EF вотум недоверия :

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

Эссе не содержит каких-либо доказательств в поддержку своих утверждений, но заставило меня усомниться в подходе CDM достаточно долго, чтобы попробовать альтернативу, и получающееся в результате программное обеспечение не взорвалось ни в прямом, ни в переносном смысле. Но это не значит много в изоляции; Мне бы просто повезло.

Поэтому мне интересно, проводились ли какие-либо серьезные исследования практических, долгосрочных последствий наличия канонической модели в сравнении с контекстными моделями в программной системе или архитектуре?

Или, если еще слишком рано об этом спрашивать, то написали ли разработчики / архитекторы о личном опыте перехода с CDM на независимые контекстные модели или наоборот, и как это повлияло на такие вещи, как производительность, сложность или надежность?

Как насчет различий на разных уровнях, т. Е. Использование одной и той же модели в одном приложении или ее использование в системе приложений или на всем предприятии?

(Только факты, пожалуйста; истории войны приветствуются, но не спекуляции.)

Aaronaught
источник
Я понятия не имею, о чем они говорят в статье «Голосование без доверия». Остальная часть статьи имеет смысл, но раздел о канонизме настолько абстрактен, что ничего не значит. Было бы неплохо, если бы они привели пример того, о чем они говорили.
Роберт Харви
@ Роберт: Я понятия не имею, есть ли в этом какая-то правда, но мне совершенно ясно, что это значит ... конечно, вы знакомы с шаблонами CM / CDM? В своем простейшем воплощении он разделяет одну монолитную модель / контекст EF (или Linq to SQL, или что угодно) во всем приложении вместо более (воспринимаемого) клейкого подхода к написанию конкретных запросов для определенных частей приложения. На более высоком уровне он принимает универсальную схему для всей организации, в которую должны преобразовываться все отдельные приложения / системы.
Aaronaught
1
Похоже, что дискуссионные центры EF основаны на том, что таблица сначала сравнивается с конструкцией класса, так как схема таблицы (где классы создаются из таблиц) предполагает монолитную модель (хотя всегда есть специализированные запросы и представления), а модель класса - сначала. (где таблицы генерируются из классов) предлагает более гибкую модель OO. Я немного староват, предпочитаю настольный подход, но я мог видеть, насколько привлекательным для некоторых был бы подход «первым делом».
Роберт Харви
@ Роберт, я не собирался поднимать «дебаты об EF», я просто взял одну цитату из этой страницы, потому что именно там я впервые услышал аргумент (и я не уверен, слышал ли я его четко выражено где-то еще). Отдельно я не уверен, что согласен с тем, что табличный дизайн на самом деле представляет собой монолитную модель; база данных сам по себе есть, но только СУБД действительно осознает , что - разные части приложения , как правило, только осведомлено о конкретных таблицах и запросах они зависят.
Aaronaught

Ответы:

5

В ответ на статью EF «Голос за недоверие» Тим Маллиу пишет:

Мы не рекомендуем возвращаться к тем дням, когда мы проповедовали использование XSD для «канонических схем». Я не верю, что люди думают, что это поддается лечению. Однако мы верим, что желательно иметь единую метамодель (EDM, если хотите), с помощью которой вы можете описать множество моделей предметной области, и что, имея единую грамматику, мы можем предоставить набор общих служб для любого данная модель предметной области.

Например, рассмотрим приложение, которое должно быть записано в базу данных с 600 таблицами. Верю ли я, что в этом приложении должна быть одна модель с 600 типами объектов? Нет ... Кроме того, считаю ли я, что какой-либо конкретный объект домена (скажем, Клиент) имеет только одну форму в этом приложении и что эта форма должна быть канонической формой для всего Предприятия? ... Черт, нет.

В статье Wikipedia для Canonical Model упоминаются такие вещи, как Enterprise Service Bus , Service-Oriented Architecture и CORBA , вещи, о которых кажется, что о них больше не говорят. Все они были поставлены как решение проблем распространения данных и коммуникаций на предприятии, « Единый звонок, чтобы управлять ими всеми». Т.М. Им это удалось? Или они развалились под собственным весом?


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

Что означает «высота»? Это высота над землей или высота над уровнем моря? Что если вы говорите о подводной лодке? Тогда его глубина, а не высота. Для армии слово «передача» имеет другое значение, когда вы имеете в виду радиолокационную антенну, а не наземное транспортное средство. Поверхность крыла, которая вызывает крен самолета, на одних самолетах называется элероном, а на других - элевоном.

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


Проблемы, с которыми сталкиваются крупные компании, похожи. Microsoft склонна мыслить монолитно, но это потому, что их компания в целом монолитна. Как только вам нужно будет общаться между разными компаниями с совершенно разными культурами и способами ведения бизнеса (или даже между разрозненными отделами в одной и той же компании), « Одно кольцо - управлять ими всеми». ТМ сразу начинает ломаться.

Роберт Харви
источник
Интересно знать, что сами дизайнеры Microsoft не рекомендуют общую мегамодель; к сожалению, именно так обычно используются Linq для SQL, EF и многие другие ORM. Несмотря на это, все еще есть много людей, продвигающих концепцию канонической модели, и я все еще хотел бы знать, как это происходит на практике по сравнению с альтернативой.
Aaronaught
@Aaronaught: см. Мое редактирование.
Роберт Харви
Это хорошая редакция, и, к вашему сведению, я проголосовал за нее. Однако я уже знаю о многих специфических проблемах несоответствия, которые возникают при попытке канонизировать модель; Мне особенно интересно узнать об опыте или долгосрочных данных о командах, которые потратили время на устранение этих несоответствий, чтобы иметь один маппер на конечную точку (от конца к модели), вместо того, чтобы вкладывать время в отдельный конец вместо этого - картографы и подходы, которые позволили получить решения с наименьшими затратами и наименьшей сложностью.
Aaronaught
Или, если выразить это более кратко: я знаю, что для создания и поддержания канонической модели необходимо проделать большую работу, и я хочу знать, когда (если вообще когда-либо) наблюдаются преимущества, которые перевешивают стоимость.
Aaronaught