Petro123Приведи маппинг 2-х проектов одновременно в одном проекте-модели.
Здесь я выкладывал пример проекта. Там на основе одних и тех же исходников можно получить две версии БД - Shareware_Version и Free_Version, с разным функциональном составом, соответственно и получить две case-модели. Возможно этот демо-примерчик слабовато показателен в рамках какой-то динамичности ER-модели, т.к. там нет инвариантов структур таблиц. Попробуем пофантазировать. Там есть таблица "BOOKS" - некий список книг. Всего заранее никогда не предусмотришь, через какое-то время, когда проект работает в куче мест, какому-то клиенту захотелось иметь код ISBN ("кривости" проектирования исходного демо-примера опускаем, у него другая задача). Добавляется новое поле в таблицу, во всех инсталяциях вносятся соответствующие изменения. Причём обращаю внимание, что в подобных случаях никто не заморачивается какими-то версиями, поле добавляется всем, считая, что если кому-то оно не нужно, то это его воля, сегодня не нужно, а завтра дай. Далее, кому-то понадобилось удобно формировать заказы для своего поставщика, а у того есть своя кодировка книг, причём логика которой подогнана под тип Integer. Хорошо, добавили новое поле "ID_EXTERNAL" нужного типа. Другой заказчик тоже захотел пользоваться новой фишкой, но у его поставщика своя специфичная кодировка, на основе строки с буквами. Проанализировали уже имеющийся код, прикинули, что вроде как без особого гемора можно заменить тип столбца "ID_EXTERNAL" на строковый, как универсальный вариант, и хрен с тем, что индексы на основе Integer эффективнее. Но оказалось, что у какого-то заказчика уже имеется какой-то сторонний софт, который работает с теми же данными и уже прибит к типу Integer. Фигня, возникает потребность уже иметь две версии одного и того же поля "ID_EXTERNAL", и поддерживать их хотя бы какое-то время (но ничто постоянно так как временное). Типовой ООП-мейнстрим вынуждает в большинстве случаях реализовывать какой-то один универсальный вариант, не всё можно выразить через иерархии, связываться с разными классами как какими-то вариантами фактически одного и того же дюже геморно, и, к примеру, в конечном итоге мейнстрим вынудит поместить в таблицу "BOOKS" (по сравнению с исходной версией) столбец ISBN и столбцы "ID_EXT_INT" и "ID_EXT_CHAR" на каждый чих. Будет и соответствующий мапинг, причём как правило, всем фиолетово, что в ряде случаев из-за не использования данных будет напрасная обработка полей, коллекции будут напрасно хавать память и т.п., если вдруг и возникнут проблемы, то это уже сваливается на голову эксплуатирующих, пусть они занимаются "правильным" железом. К тому же отсутствие гибких динамических средств как в клиентском, так и в серверном коде может подталкивать к использованию не всегда оправданных универсальных средств. Например, потребовалось где-то группировка данных, но с разными вариантами на местах. Якобы чтобы быть от греха подальше, делают классическое дерево с произвольным уровнем вложенности, твори что хочешь, но на практике в данном случае более чем достаточно поддержки максимум 3-х уровней, просто есть разная их потребность (где-то структуризация не используется, где-то только группы, где-то плюс подгруппы и где-то максимум вид/тип/класс и группа с подгруппами). Или из-за разного набора столбцов для одного и того же в разных случаях в качестве альтернативы вместо впихивания всего в одну кучу прибегают к еntity–attribute–value model. Подобные решения могут помочь в одних случаях, но вылезти боком в других, включая и существенную просадку в производительности.
Я не говорю о том, что нужно всё оптимизировать на каждый чих, это невозможно. Но на практике при немалом количестве проектов и не на одной инсталяции с годами возникает куча нюансов, и жизнь заставляет в ряде случаев выкручиваться неожиданно по самое не могу, и хорошо, когда есть платформа для гибких выкрутасов.
Petro123PSV100,
Мейнстрим сейчас это декларативность. А это статика. Аннотации жестко гвоздями маппят модель.
Чтобы был проект Паровоз и проект Ракета. А не один проект ПаровозоРакетоМобиль.
Ведь лапша код же получается?
Да нет никакой лапши. Продолжим псевдо-пример. Через какое-то время кому-то понадобилась полноценная продавалка этих книг, с блэкджеком и шлюхами. Фактически появляется новый проект, назовём его "SALE", где будет управление запасами, поставщиками, покупателями и пр. (а точнее, проект будет обладать лишь частью этих функций). Исходный проектик фактически вырождается в некий справочник вокруг книг как товара, назовём его "SPR". Реорганизуем каталог исходников начального демо-примера, где разделим файлы согласно своим проектам по одноименным каталогам. Теперь соответствующий инструментарий (о котором здесь пытаются говорить) позволит для одних случаев создавать/модифицировать/разрабатывать и пр. те базы, где есть только справочник (как простейшая учётная система), так и те, где есть и "SALE", при этом этот "SALE" тесно повязан с "SPR". Далее, со временем появляется проект для производства этих книг - некий "PRODUCTION", оформляем его также рядом с остальными проектами. Как и "SALE", он тоже пользуется общим справочником из "SPR", а также в случае, если этот "PRODUCTION" в БД будет рядом жить с "SALE", то он и с ним будет дружить, к примеру, поставляя информацию о себестоимости в качестве закупочных цен. В свою очередь, каждый проект (или уже подпроект) будет дружить с элементами бухучёта, если и его подселят где-то. Наличие в БД разного состава проектов может влиять на структуру объектов в БД, например, для той же таблицы "BOOKS" будут созданы соответствующие foreign key в зависимости от того, есть ли в БД связанные таблицы согласно внедрённым проектам, или добавлены или нет какие-то триггеры и т.п. В реальной жизни кроме всяких общих справочников есть широкий общефункциональный слой - управление функциональными участками с контролем состояний и всякого доступа (в т.ч. это основа для генераций "grant"-ов), журналы для отслеживания изменений и т.д. и т.п. Причём не всегда допустимо, скажем, внедрять какой-то подпроект в целом виде. К примеру, пусть тот же "SPR" фактически превратился в широкую "schema", где живут общие справочники для остальных подпроектов. Но не всегда необходимо в базе держать весь зоопарк, скажем, если необходимо организовать рабочее место какого-то кассира, где используется своя локальная база, изредка синхронизируясь с каким-то сервером, и для этой задачки необходимо пару десятков таблиц, то сваливать в эту базу ещё сотни неиспользуемых объектов как-то некошерно (хоть и не смертельно).
Таким образом, наш каталог исходников вырождается в такую структуру:
- RootProject
|- SPR
|- SALE
|- PRODUCTION
Т.е. есть каталог проекта, в корне которого свои специфичные общие файлы (что именно - сейчас не важно) и по каждому подкаталогу распределены файлы подпроектов/модулей. На основе одних и тех же исходников можно управлять базами, где есть только SPR (точнее, его часть), где есть только SALE, где есть только PRODUCTION, так и возможно любое сочетание этих прикладных модулей, со своими вариантами (если инструментарий позволяет). Соответственно в каждом конкретном случае после настроек и всяких проектирований можно получить нужную case-модель, отражающую текущую сложившеюся ситуацию в каждом конкретном случае на каждом конкретном месте.
Обращаю внимание, что речь идёт именно о взаимосвязанных проектах/подпроектах/модулях, смешивать в одну кучу, скажем, модули вокруг ERP-мути и проект разработки сайта для википедии никто не будет.
Теперь о том, если пытаться проектировать на основе ER- и подобных моделей. Опускаем потенциал для возможной инвариантности функционала (хотя на практике это может стать колом, что в своё время оттолкнуло от них, это кроме неподдержки нужных СУБД, отсутствия элементарного удобства в работе из-за соответствующих GUI-интерфейсов (но это вкусовщина)). Я уже очень давно не занимаюсь визуализацией, и откровенно говоря так и не постиг нирваны с case-средствами. Я не представляю как лучше поступать в таких случаях. Если лепить одну большую case-модель как единый проект, то сомневаюсь в том, что получится грамотно под свои нужды вырезать куски или обрабатывать частично, скорее всего, придётся опять мучительно програмлять для себя (и накой тратить не одну тыщу на визуальный инструмент, терпеть его причуды и опять по-своему пилить вручную (речь, конечно, не идёт о каких-то корпоративных заморочках)). Если лепить отдельные модели для каждого подпроекта, то возникает неоднозначность с общим функционалом, либо его нужно везде дублировать, либо выделять тоже отдельной моделью, но как-то отражать связи. Не помню, что там в ER, но вроде как в IDEF-стандартах есть некие абстрактные связи, когда стрелочки приходят ниоткуда и уходят в никуда (или куда душе угодно, и то это касательно процессов, насчёт данных уже не помню). Во всяком случае, насколько я помню, многие case-средства большие любители создавать некие условные виртуальные копии объектов, чтобы упростить визуальную компоновку на экране, уменьшая лес линий и пр. Возможно, через подобные копии что-то можно отразить (хотя это опять, фактически, дублирование функционала).
Собственно, если кто-то укажет на правильную методику в таких случаях, буду признателен.
