Кодируйте Сначала или База данных Сначала, как выбрать?
Столкнулся с той же проблемой. Перезапуск углового сервера ng-serve работал для меня.
8 ответов
Я думаю, что правильный подход к системному анализу и проектированию - это начать с моделирования ваших объектов и отношений между ними. Если вы создаете библиотечную систему, вы должны рассматривать фразы «Книга», «Автор», «Издатель», ISBN как объекты, а не как таблицы или атрибуты базы данных. Я считаю, что так и должно быть. При этом давайте признаем, что генераторы кода экономят много времени, и им требуется реляционная база данных, чтобы сгенерировать модель и сопоставить ее с объектами БД. Я думаю, что это основная причина, по которой разработчики склонны начинать с БД. Что еще может доказать мою точку зрения, так это то, что разработчики генераторов кода изо всех сил пытаются изменить текущую реализованную операцию (т. Модель First :
Visual Studio 2010 должна иметь возможность генерировать DDL и создавать базу данных для хранения модели данных объекта. Разработчик имеет полный контроль над всем процессом, имея возможность настраивать DDL или выбирать нужную базу данных, или точно настраивать процесс сопоставления.
Почему не сначала интерфейс?
Слишком многие приложения запускаются с менталитетом сначала программы. Это плохая идея. Программирование - это самый тяжелый компонент при создании приложения, а это значит, что его сложнее всего изменить. Вместо этого начните с проектирования.
Дизайн относительно легкий. Бумажный эскиз дешевый и его легко изменить. html-дизайн по-прежнему относительно легко изменить (или выбросить). Это не относится к программированию. Дизайн прежде всего сохраняет гибкость. Программирование сначала ограждает вас и требует дополнительных затрат.
Это из главы 9 из Реализация 37signals.
“Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.”
— Fred Brooks in “The Mythical Man-Month”
На мой взгляд, на этот вопрос нет правильного ответа. Я думаю, это в основном сводится к вашим личным предпочтениям или предпочтениям вашей команды. Все упомянутые подходы (сначала база данных, сначала код, сначала интерфейс) имеют свои преимущества и недостатки.
Я бы, наверное, сел с ручкой и бумагой и набросал общую структуру и основные функции приложения, прежде чем что-либо делать конкретные, будь то код или таблицы базы данных. Также очень помогает простой рисунок основного пользовательского интерфейса.
Сначала анализ требований, а затем некоторая документация по этим потребностям и обзор аспекты данных?
Тогда вы знаете, какие данные вы собираетесь собирать и как они соотносятся с другими данными, и можете разработать схему базы данных или структуру данных в соответствии с ней (в виде логических объектов / таблиц связанного содержимого, а не "tab1_data", "tab2_data" соответствуют процессу захвата данных, который может измениться, но вы это знаете!). Вы даже можете сначала спроектировать .xsd и сгенерировать из него код и схему базы данных. В наши дни это все развлечения и игры, в зависимости от вашего набора навыков.
Поскольку схема базы данных в моем понимании хранит данные, а это действительно важная вещь для бизнеса, я бы спроектировал ее первым - несколько инструментов могут получить к ней доступ со временем, возможно, исходная система будут заменены в будущем (например, переход на более новые инструменты / языки / интерфейсы). Если вы ничего не знаете о теории баз данных, то, возможно, это не лучший вариант, но я все равно получу любую сгенерированную схему, проверенную кем-то другим.
В большинстве случаев это не имеет большого значения. Это больше зависит от личных предпочтений и навыков, чем от чего-либо еще. Большинство приложений в любом случае не пострадают, используйте все, что удобно вашей команде. Когда выбор действительно имеет значение, должно быть очевидно, какой подход выбрать.
Тем не менее, мое личное мнение таково, что «сначала база данных», как правило, более безопасный выбор. Если данные каким-либо образом важны, особенно если они важны за пределами вашего конкретного приложения, вы хотите иметь полный контроль над тем, как они хранятся.
«Сначала код» (подразумевается: оставление базы данных в руках какого-то автоматического инструмента), на мой взгляд, действительно ярлык, который вы должны использовать тогда (и только тогда), когда вы точно знаете, что вам это сойдет с рук.
Чтобы ответить на ваш отредактированный вопрос (ручные классы db / auto или ручные классы / db), я бы выбрал «ни один». Автогенерированный код обоих видов следует избегать по ряду причин, прежде всего по YAGNI. В итоге вы получаете код, который вы никогда не писали, но за который, тем не менее, несете ответственность, код, который вы никогда не будете использовать, и (по моему опыту) код, на рефакторинг которого вы в конечном итоге потратите больше времени, чем если бы вы спроектировали и написали его самостоятельно вначале. место. И оба они отвлекают ваше внимание от самого важного места - пользователя.
Начните с того, что не думайте напрямую, а скорее «моделируйте» (желательно на бумаге), какие части ваше приложение будет иметь с точки зрения пользователей.
Если у вас есть четкое представление об этой модели, вы можете разделить части на общие и конкретные небольшие элементы, которые можно преобразовать как в определения объектов, так и в таблицы базы данных.
Я считаю, что этот метод сокращает время нормализации базы данных и приложить значительные усилия.