Comments 15
А конкретный пример? Чем это отличается от рельс со скаффолдингом, к примеру?
Я сознательно не уходил в конкретную технологию, поскольку целью было описать подход, а не какой-то конкретный фреймворк.
Ruby on Rails в статье кстати тоже упомянут, и может быть использован в качестве основы для построения системы управления данными при исползовании соответствующего языка программирования.
Скаффодинг в принципе тут рассматривается как ключевое понятие.
Ruby on Rails в статье кстати тоже упомянут, и может быть использован в качестве основы для построения системы управления данными при исползовании соответствующего языка программирования.
Скаффодинг в принципе тут рассматривается как ключевое понятие.
Мне кажется, вы ему придаете слишком большое значения. Для большинства приложений сложнее блога скаффолдинга недостаточно, да и в блоге… нужно как минимум поменять view, подредактировать контролеры на предмет всяких notices, возможно изменить или дописать роуты. Скаффолдинг — экономия времени в некоторых случаях, и не более того.
Естественно, серебряной пули которая решала бы все проблему — не существует.
И я этого вовсе не утверждал в статье. Здесь описан подход к архитектуре в целом, где скаффолдинг позволяет решать именно те задачи для которых предназначен.
Свои проекты я строю именно с применением такого подхода, и он очень сильно экономит время и ресурсы.
Возможно кому-то он так же поможет работать более эффективно.
И я этого вовсе не утверждал в статье. Здесь описан подход к архитектуре в целом, где скаффолдинг позволяет решать именно те задачи для которых предназначен.
Свои проекты я строю именно с применением такого подхода, и он очень сильно экономит время и ресурсы.
Возможно кому-то он так же поможет работать более эффективно.
Как боретесь с миграциями в базах?
Особенно значимых когда перекраивается много сущностей? Ведь в таком случае просто перегенерировать скаффы будет не достаточно, может очень много боков повылазить, при условии что важно не потерять существующие данные
Особенно значимых когда перекраивается много сущностей? Ведь в таком случае просто перегенерировать скаффы будет не достаточно, может очень много боков повылазить, при условии что важно не потерять существующие данные
В случае кардинального изменения структуры базы данных (в моей практике такое было в двух проектах где я использовал подобный подход) мне было необходимо только сгенерировать новую модель классов для ORM (в моем случае EntityFramework) и по новой прописать некоторые атрибуты (для своих проектов я написал специальную утилиту, которая добавляет большинство атрибутов автоматически и мне необходимо после только просмотреть код и вручную сделать небольшие изменения).
В итоге на эту операцию у меня ушло часа 4, плюс еще несколько дней на реализацию новой бизнес-логики (но это как раз и был тот новый функционал ради которого и делались изменения в базе данных).
При этом конечно не все формы были результатом генерации, были также специфические формы, которые писались отдельно.
В итоге на эту операцию у меня ушло часа 4, плюс еще несколько дней на реализацию новой бизнес-логики (но это как раз и был тот новый функционал ради которого и делались изменения в базе данных).
При этом конечно не все формы были результатом генерации, были также специфические формы, которые писались отдельно.
Вообще же, я хочу заметить, что описанное вами — тот еще велосипед. Этот велосипед есть и в asp.net (та самая dynamic data), и для asp.net mvc реализуется без каких-либо проблем на основе editor/display templates, и только ленивый их сам для себя не писал.
Потому что ужасно же вкусная идея: поскольку операции с данными, типа, всегда одинаковые, давайте сделаем «универсальный механизм». Проблема в том, что в реальности данные оказываются удивительным образом разные, и вокруг механизма сначала наворачиваются костыли «описаний», а потом, когда их оказывается недостаточно, добавляют возможность использования нормального языка программирования, сводя все это к IPS.
Been there, seen that: две таких системы сам написал, третью год назад унаследовал.
Проблемы у всех одни и те же: как только система становится достаточно настраиваемой, чтобы удовлетворить любому пожеланию заказчика, она превращается в урезанное и глючное подобие той платформы, на которой написана.
Потому что ужасно же вкусная идея: поскольку операции с данными, типа, всегда одинаковые, давайте сделаем «универсальный механизм». Проблема в том, что в реальности данные оказываются удивительным образом разные, и вокруг механизма сначала наворачиваются костыли «описаний», а потом, когда их оказывается недостаточно, добавляют возможность использования нормального языка программирования, сводя все это к IPS.
Been there, seen that: две таких системы сам написал, третью год назад унаследовал.
Проблемы у всех одни и те же: как только система становится достаточно настраиваемой, чтобы удовлетворить любому пожеланию заказчика, она превращается в урезанное и глючное подобие той платформы, на которой написана.
Аналогичное решение для php:
Sign up to leave a comment.
Проектирование веб-приложений с применением Data Management System (на основе технологии скаффолдинга)