Прикольно, столько времени спустя это кто-то читает.
Я отвечал на аналогичный вопрос уже вот тут.
Суть не только в качестве инструментария, а в принципе в подходе: выполнялось ли проектирование и есть ли модель. Ибо попадают системы, писанные по 5-7 лет людьми, надо же как-то понимать, о чем они думали. Восстанавливать это по исходникам и структуре базы — обычно очень трудно, старый комментарий это иллюстрирует.
Насчет:
визуальные редакторы могут и всякого наворотить, и комментарии после их воздействия могут неожиданно исчезать, и прочие подобные неожиданности
— так это от инструментария зависит, тут под одну гребёнку не сильно погребёшь.
Ну, опять двадцать пять.
Я не спорю с тем, что прижилось, а что нет, спорить с этим бессмысленно. Как пишут, так пишут. И всё, факт. Нужно с ним считаться, хочется мне или нет.
Но при этом никто не мешает дать мне свою оценку, да и послушать, что народ скажет.
Вы — субъект и я субъект. Обе наши оценки субъективны. И значения их, думается, одинаковы. А далее, каждый читатель решает для себя.
За сим, предлагаю закруглиться и далее не флеймить.
Слушайте, я нашёл для вас диаграмму! Автоматически сгенеренную по коду. Всё равно она экспортировалась в таком виде, что разобрать детали невозможно.
Это структура сущностей средненькой системы, по которым мы консультируем.
Я думаю, всё-таки вы согласитесь со мной, что запутаться в ней довольно легко. Особенно, в случаях с недостаточным знанием предметной области
Code-first и значит, «код в первую очередь», значит идём писать код. Есть там контекст, нет контекста, как и когда пишется логика и маппинг — зависит от реализации.
Хорошо. Графические нотации (по вашему мнению) устарели. У вас есть все шансы рассказать о современных подходах.
Поясните, пожалуйста, вашу мысль. Я тоже недоволен этой реализацией. Я где-то написал, что мне нравится MF в EF? Комментирующие также все как один убеждают, что единственно верный способ — это CF.
Если мы с вами согласны, то чем в статье вы недовольны?
Я также понял, что EF вам нравится.
Также, вы в который уже раз пытаетесь перевести разговор из области фактов и инженерных подходов в область моей личности.
Зависит от системы. У меня система (долго погружаться в предметную область), в которой остатки необходимо считать в реальном времени, ну или очень близко к реальному. Например: перебор некоторой суммы означает реальные материальные потери для пользователя.
Ну, не рисуйте. Разве я настаиваю? Вы используете CF, вам это нравится, мне нет. Я же за это не пытаюсь вам давать мою личную эмоциональную оценку.
«Общая практика» — вообще вещь странная. Люди же что-то новое изобретают? Оно обычно противоречит общей практике, и что?
За непонимание чего? Того, что «большинство используют EF совершенно не так как вы описали»? Я это понимаю, в чем вопрос? Мне было интересно, как используют, я получил ответ, действительно пользуют code-first. Поясните мысль про астронавтику.
Сам принцип CF (как подхода к проектированию) мне не нравится. И мне кажется, что непопулярность MF (как подхода к проектированию, я подчёркиваю) объясняется качеством реализации в EF.
А я, собственно, не предлагаю заставлять проектировщика или аналитика прорабатывать систему в деталях, как и пользоваться для этого студией. «Проектировать надо в инструментах для проектирования — а не в студии» — сильно сказано, я подписываюсь под этим тоже. Хорошо также, когда инструмент проектирования позволяет довести модель до программиста. Вот что я хотел сказать.
Жаль, что я не могу показать «сгенерированной по коду диаграммы», ни одной. Но очень бы хотелось. :-)
Из модели для презентации — конечно нет. :-)
Но вообще-то моделирование с генерацией исходного кода активно применяется.
Причем, для самых разных задач. Помню, лет 15 назад меня сильно поразил один продукт, в котором на UML-based языке (как пример) была запущена стиральная машина. И дебажить было можно прямо по диаграмме.
И сейчас знаю, в т.ч. отечественные конторы, которые делают как рилтайм, так и бизнес-автоматизацию с применением аналогичных подходов, более или менее формальных и проработанных.
Опять отвлеклись :-)
Вот в этом я с вами никогда не соглашусь.
Есть вопрос легкости восприятия.
Идите расскажите заказчику, что он должен вникнуть в ваш код. А и кода ещё и не бывает в моменты обсуждения, до него тупо не дожили.
Я предпочитаю обсуждать с ним картинки. Нет-нет, конечно, я не гружу его структурой сущностей в деталях. Однако use-cases, activity, sequence, statechart, вполне адекватно воспринимаются практически любым заинтересованным неподготовленным человеком. Это легко осваивается. На крайняк, люди любят BPML (правда, я обычно не использую).
Так что проектирование должно идти от картинок, плавно трансформируясь в структуры сущностей, алгоритмов и т.п.
Опять отвлеклись :-)
Подход подходу рознь. Сильно зависит от проекта, людей, внешних условий, корпоративных политик, размеров контор и т.п.
К великому сожалению, у большинства унаследованных проектов даже при наличии подхода модели сущностей нет и её приходится восстанавливать по базе или по коду.
Я отвечал на аналогичный вопрос уже вот тут.
Суть не только в качестве инструментария, а в принципе в подходе: выполнялось ли проектирование и есть ли модель. Ибо попадают системы, писанные по 5-7 лет людьми, надо же как-то понимать, о чем они думали. Восстанавливать это по исходникам и структуре базы — обычно очень трудно, старый комментарий это иллюстрирует.
Насчет: — так это от инструментария зависит, тут под одну гребёнку не сильно погребёшь.
Я не спорю с тем, что прижилось, а что нет, спорить с этим бессмысленно. Как пишут, так пишут. И всё, факт. Нужно с ним считаться, хочется мне или нет.
Но при этом никто не мешает дать мне свою оценку, да и послушать, что народ скажет.
Вы — субъект и я субъект. Обе наши оценки субъективны. И значения их, думается, одинаковы. А далее, каждый читатель решает для себя.
За сим, предлагаю закруглиться и далее не флеймить.
Это структура сущностей средненькой системы, по которым мы консультируем.
Я думаю, всё-таки вы согласитесь со мной, что запутаться в ней довольно легко. Особенно, в случаях с недостаточным знанием предметной области
Хорошо. Графические нотации (по вашему мнению) устарели. У вас есть все шансы рассказать о современных подходах.
Если мы с вами согласны, то чем в статье вы недовольны?
Также, вы в который уже раз пытаетесь перевести разговор из области фактов и инженерных подходов в область моей личности.
«Общая практика» — вообще вещь странная. Люди же что-то новое изобретают? Оно обычно противоречит общей практике, и что?
Жаль, что я не могу показать «сгенерированной по коду диаграммы», ни одной. Но очень бы хотелось. :-)
Изучайте исходники с коллегами. Или фольклорным способом. :-)
Но вообще-то моделирование с генерацией исходного кода активно применяется.
Причем, для самых разных задач. Помню, лет 15 назад меня сильно поразил один продукт, в котором на UML-based языке (как пример) была запущена стиральная машина. И дебажить было можно прямо по диаграмме.
И сейчас знаю, в т.ч. отечественные конторы, которые делают как рилтайм, так и бизнес-автоматизацию с применением аналогичных подходов, более или менее формальных и проработанных.
Опять отвлеклись :-)
Есть вопрос легкости восприятия.
Идите расскажите заказчику, что он должен вникнуть в ваш код. А и кода ещё и не бывает в моменты обсуждения, до него тупо не дожили.
Я предпочитаю обсуждать с ним картинки. Нет-нет, конечно, я не гружу его структурой сущностей в деталях. Однако use-cases, activity, sequence, statechart, вполне адекватно воспринимаются практически любым заинтересованным неподготовленным человеком. Это легко осваивается. На крайняк, люди любят BPML (правда, я обычно не использую).
Так что проектирование должно идти от картинок, плавно трансформируясь в структуры сущностей, алгоритмов и т.п.
Опять отвлеклись :-)
К великому сожалению, у большинства унаследованных проектов даже при наличии подхода модели сущностей нет и её приходится восстанавливать по базе или по коду.
Мы уже далеко отдалились от темы. :-)
Мой опыт показывает, если нет однозначного подхода, нет моделей, — нет контроля, жди сюрприза.