Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
с чего вдруг такой интерес к расширению UML - для меня осталось загадкой.Народ хочет код генерить во всю, наверное...
П. Пользователь приходит на сайт
Н. Пользователь получает нужное
Д. Пользователь остаётся довольным
Р. Пользователь рекомендует сайт знакомым
В. Пользователь возвращается на сайт
View - это больше мои предположения как можно удобнее организовать представление. Я сам склоняюсь к тому, что наиболее существенный это Class centric view.
Не описана проблема, на решение которой направлена данная нотация. "Я пришёл к администратору БД, а он мне - ..., а я ему - ..., а он мне ... и пошёл я с понурой головой" - это не проблема. Как из этой дискуссии вытекает мысль "нам нужен инструмент для ORM-моделирования", мне не понятно.Ну вроде проблема описана - если мы проектируем БД, то получается неадекватная модель классов и наоборот, для этого и нужна нам ORM диаграмма. Да согласен, "слюни" надо убрать про хождение к начальству...
Зачем вообще нужна нотация, визуализировать очевидное? Не понятно.Ну вроде Максим ответил мне на этот вопрос в процессе переписки:
Видимо есть недопонимание, того что предлагается: предлагается нотация, которая допускает генерацию как модели по структуре БД (ER) и ORM диаграммы так и генерации ER на основе модели и ORM диаграммы. Естественно из полученной диаграммы можно прогенерировать сам код как таблиц так и классов так и mapping.
Да есть не допонимаение. Нигде я не нашел в вашей статье (м.б. не внимательно читал), что предполагается именно это, т.е. генерация модели из ER+ORM или генерация ER из модели+ORM. Тогда идея неплохая.
Про стилистику, грамматику и орфографию уже не пишу.Да, лучше бы на русском ....
Видимо есть недопонимание, того что предлагается: предлагается нотация, которая допускает генерацию как модели по структуре БД (ER) и ORM диаграммы так и генерации ER на основе модели и ORM диаграммы. Естественно из полученной диаграммы можно прогенерировать сам код как таблиц так и классов так и mapping.
Да есть не допонимаение. Нигде я не нашел в вашей статье (м.б. не внимательно читал), что предполагается именно это, т.е. генерация модели из ER+ORM или генерация ER из модели+ORM. Тогда идея неплохая.
Вы справедливо заметили, что нет упоминания о генерации модели из ER+ORM или генерации ER из модели+ORM. Это связанно с тем, что я хотел бы сначала вынести на обсуждение саму нотацию, а потом механизмы которые могут быть заложены в инструмент реализующий нотацию.
> Прочитал статью, впринципе идея интересная, но т.к. я плохо знаком с ORM, в частности с Hibernate и пр., мне трудно судить вашу статью.
> Первые впечатлении такие:
> 1. Не увидел как это все генериться в код и генериться ли вообще.
Видимо есть недопонимание, того что предлагается:
предлагается нотация, которая допускает генерацию как модели по
структуре БД (ER) и ORM диаграммы так и генерации ER на основе модели
и ORM диаграммы.
Естественно из полученной диаграммы можно прогенерировать сам код как
таблиц так и классов так и mapping.
> 2. Мне, например, более ближе идея тогда уж MDA, в частности, BOLD & ECO. Уж слишком много у вас надо построить - ДК, ЕР диаграмму и еще ORM диаграмму.
На мой взгляд в процессе проектирования, сейчас тем или иным методом
создаются ДК, ЕР диаграмму, однако ORM генерируется, чот приводит либо
к не идеальной БД либо к не идеальной модели и трудно контролировать,
когда нужно как сам ORM так модель или структуру БД.
> 3. Почему ваш мапинг нельзя сделать обычными средствами диаграмы ЕР или ДК? Просто показать некий связующий мапинг класс в середине, и к нему с одной стороны идут таблицы, с другой классы, а в себе он аккомулирует поля для мапинга.
Можно отрисовать, как я в приципе и сделал на Dia и ArgoUML, но нельзя
полноценно управлять сущностями проектирования: например генерировать
одно из другого, и генерировать как таблицы так и классы так и ORM
mapping.
