Почему бы не создать UI на основе схемы DB?
Я делаю его точкой для записи комментариев Javadoc каждый раз, когда это нетривиально, Пишущий комментарии Javadoc при использовании IDE как затмение, или netbeans не настолько неприятен. Кроме того, когда Вы пишете комментарий Javadoc, Вы вынуждаетесь думать о не, что метод делает, но и что метод делает точно , и предположения, которые Вы сделали.
Другая причина состоит в том, что, как только Вы поняли свой код и осуществили рефакторинг его, javadoc позволяет Вам забывать, о каком он делает, так как можно всегда обращаться к нему. Я не рекомендую намеренно забывать то, что делают Ваши методы, но это просто, что я предпочитаю помнить другие вещи, которые более важны.
10 ответов
Я хотел бы отметить, что в прошлый раз, когда я проверял, .NET и Qt (и, возможно, другие среды) позволяют использовать «виджеты с учетом базы данных» (иногда сокращенно до виджеты с поддержкой данных), что, вероятно, является лучшим доступным прагматическим решением. Под виджетами с поддержкой данных я подразумеваю то, что сами виджеты знают, что они связаны напрямую с полями базы данных, поэтому у вас будет поле со списком, которое знает, что оно поддерживается перечислением и извлекает возможные значения непосредственно из базы данных во время выполнения, как вы и предположили.
Это действительно отличная утилита, и при правильном использовании она, вероятно, никому не повредит. Это по-прежнему требует, чтобы вы потратили некоторое время на размещение виджетов вручную в форме, но затем, если вы обновите базу данных, чтобы добавить новое значение в это перечисление, вы не не нужно перестраивать приложение, чтобы оно отображалось в пользовательском интерфейсе.
Но причина, по которой большинство экспертов по юзабилити будут съеживаться, услышав ваш вопрос, заключается в том, что программисты склонны думать, что почему бы просто не сгенерировать весь Пользовательский интерфейс, макет формы и все остальное из базы данных? И здесь это начинает становиться действительно неприятным, очень быстро.
Допустим, у вас есть простая таблица Person с first_name, last_name, email_address, street_address, city, state, zip и phone_number. Вы хотите автоматически создать пользовательский интерфейс на основе этих полей. Как вы сортируете поля? Я имею в виду, что в идеале имя и фамилия должны быть рядом друг с другом. И было бы очень глупо, если бы перед адресом был указан город и штат. Поэтому вам нужно добавить новый столбец в таблицу, чтобы указать порядок сортировки, если вы выберете самый быстрый метод, или новую таблицу, чтобы указать индекс порядка каждого поля для их идентификатора поля.
Что, если вы хотите сгруппировать части информации отдельно? Затем вам нужно добавить больше специфического для пользовательского интерфейса мусора в макет вашей базы данных (чтобы сделать это в целом, вам понадобится новая таблица, определяющая, какие поля пользовательского интерфейса принадлежат каким групповым ящикам пользовательского интерфейса). Итак, вы решили только две проблемы, и макет вашей базы данных уже стал вдвое уродливее, плюс теперь вместо простой операции макета O (1) при загрузке пользовательского интерфейса вам нужно выполнить несколько запросов к базе данных, чтобы узнать, какие поля существуют и динамически размещать их, применяя правильный порядок виджетов ... и мы даже не занимались изменением размеров (должно ли каждое поле иметь максимальный размер, чтобы соответствовать его возможному содержимому, или все текстовые поля должны быть одинаковой ширины? Было бы хорошо, если бы вы могли сказать, что некоторые текстовые поля должны иметь одну ширину и высоту, а некоторые - другую комбинацию? и т. д.), или текстовое выравнивание, или форматирование, или любые другие действительно общие элементарные требования к удобству использования, которые потребуют дополнительных жертв из-за ясности и простоты схемы вашей базы данных.
Большинство визуальных редакторов баз данных. Например, phpMyAdmin .
Поскольку структура базы данных не всегда является очень хорошей логической структурой для использования пользователем, особенно в случае баз данных, которые были денормализованы намеренно из соображений эффективности.
Список проектов, реализующих эту идею.
. NET
Java
C ++
Конкретно по вашему второму вопросу: многое действительно зависит от вашей модели данных. Некоторые из них очень сложны и могут привести к неинтуитивным пользовательским интерфейсам. Возможно, для простых систем на основе CRUD предпочтительнее было бы иметь пользовательский интерфейс в качестве интерфейса к базе данных. В таком случае, я думаю, что некоторые из этих инструментов были бы замечательными. Однако для некоторых более сложных систем, где некоторые данные БД необходимо скрыть от пользователей, было бы лучше, если бы пользовательский интерфейс не отображал схему БД.
Есть много систем, которые создают интерфейс, позволяющий редактировать данные непосредственно из табличной информации. Однако интерфейсы конечного пользователя необходимо немного подправить. Возможно, вы не захотите раскрывать пользователю каждое поле в своей таблице.
Фреймворки, которые эффективно используют шаблон проектирования MVC, могут позволить вам делать все виды вещей с вашими моделями , которые являются предпочтительными способ создания новых систем (а не создание таблиц базы данных напрямую).
Чтобы ответить на ваши вопросы конкретно:
django позволяет создавать формы (и полную административную CMS) из моделей.
Это - это обычное дело.
Я бы использовал модуль языковых файлов. С помощью gettext вам нужно указать локаль для каждого языка. Лучше всего иметь отдельные файлы .po / .mo для каждого модуля или больших частей вашего сайта.
Это мое мнение. : -)
Когда мы впервые находим дубликат, мы печатаем первую строку с этим ключом и помечаем ее как напечатанную, а затем печатаем текущую строку. Для всех последующих дубликатов мы просто печатаем текущую строку. Очевидно, что для любого не-обманываемого мы просто публикуем его как запись в нашем словаре.Вероятно, есть более элегантный способ справиться с этим логическим "первым обманом" ... но это было наиболее очевидно для меня и не должно представлять никаких отменить дополнительные накладные расходы. Создание очень простого объекта / класса с его собственным состоянием (я был напечатан) было бы вариантом. Но я думаю, что это затруднит понимание общей сути кода.
Должно быть очевидно, что это можно сделать на любом языке сценариев или программирования, который поддерживает ассоциативные массивы (хэши, словари, таблицы, на любом предпочитаемом вами языке) называет их). Вы можете автоматически сгенерировать форму непосредственно из определения таблицы со встроенными интеллектуальными параметрами по умолчанию и встроенным поиском. Модель хорошо работает для разработки приложений с небольшим количеством одновременно работающих пользователей, таких как пользовательские приложения для малых предприятий, где объем хранимых данных невелик.
Если вы масштабируете более крупные реляционные БД с несколькими одновременно работающими пользователями или большие базы данных, тогда надежность и производительность становятся более важными, а отдельно созданные пользовательский интерфейс и базы данных имеют больше смысла. Когда задействовано больше пользователей, у них часто возникают разные требования, поэтому отделение пользовательского интерфейса от схемы БД делает разработку более эффективной.
Модель хорошо работает для разработки приложений с несколькими одновременными пользователями, таких как пользовательские приложения для малых предприятий, где объем хранимых данных невелик.Если вы масштабируете более крупные реляционные БД с несколькими одновременными пользователями или большие базы данных, тогда надежность и производительность становятся более важными, а отдельно созданные пользовательский интерфейс и базы данных имеют больше смысла. Когда задействовано больше пользователей, у них часто возникают разные требования, поэтому отделение пользовательского интерфейса от схемы БД делает разработку более эффективной.
Модель хорошо работает для разработки приложений с небольшим количеством одновременных пользователей, таких как пользовательские приложения для малых предприятий, где объем хранимых данных невелик.Если вы масштабируете более крупные реляционные БД с несколькими одновременными пользователями или большие базы данных, тогда надежность и производительность становятся более важными, а отдельно созданные пользовательский интерфейс и базы данных имеют больше смысла. Когда задействовано больше пользователей, у них часто возникают разные требования, поэтому отделение пользовательского интерфейса от схемы БД делает разработку более эффективной.
Обнаженные объекты находятся примерно на один шаг от этого. Они основывают пользовательский интерфейс на объектной модели, а затем сохраняют объектную модель.
Я думаю, что вы забываете учитывать пользователя в процессе проектирования, если вы так думаете. Плохая ошибка. Пользователям не нравится, когда интерфейс меняется, им особенно не нравится, если он часто меняется, поскольку тогда они не будут знать, что делать. Кроме того, если вы генерируете свой пользовательский интерфейс на лету на основе структуры базы данных, то в каком порядке будут располагаться объекты? В пользовательских интерфейсах объекты должны располагаться в таком порядке, который понятен пользователям, а не разработчикам баз данных.
Кроме того, в хорошо спроектированной базе данных есть поля, которые не предназначены для просмотра пользователями. Такие вещи, как цифровые клавиши, дата вставки, последнее обновление и т. Д. Вы не хотите автоматически открывать их для пользователей и, конечно же, не хотите, чтобы они имели возможность вносить изменения в данные в таких полях.
Наконец, если ты не Не думайте о функциональности страницы, значит, вы не делаете свою работу. Пользовательский интерфейс должен быть чем-то большим, чем просто список полей, которые можно редактировать. У вас должны быть ограничения на то, кто что может видеть, проверки данных перед вставкой в базу данных, бизнес-правила, которые необходимо применить. Вы не можете просто автоматически сгенерировать большую часть этого (и не должны, даже если бы могли!). Дизайн требует размышлений и заботы.
Теперь, что касается раскрывающихся списков, вы, конечно, можете создавать их из базы данных, а не из кода, на самом деле это лучший выбор. Просто сделайте запрос источником вашего конкретного объекта, а не списком, созданным в коде.
проверки данных перед вставкой в базу данных, бизнес-правила, которые необходимо применить. Вы не можете просто автоматически сгенерировать большую часть этого (и не должны, даже если бы могли!). Дизайн требует размышлений и заботы.Теперь, что касается раскрывающихся списков, вы, конечно, можете создавать их из базы данных, а не из кода, на самом деле это лучший выбор. Просто сделайте запрос источником вашего конкретного объекта, а не списком, созданным в коде.
проверки данных перед вставкой в базу данных, бизнес-правила, которые необходимо применить. Вы не можете просто автоматически сгенерировать большую часть этого (и не должны, даже если бы могли!). Дизайн требует размышлений и заботы.Теперь, что касается раскрывающихся списков, вы, конечно, можете создавать их из базы данных, а не из кода, на самом деле это лучший выбор. Просто сделайте запрос источником вашего конкретного объекта, а не списком, созданным в коде.
не список, созданный в коде. не список, созданный в коде.Да, этот маршрут уже пройден.
Простое указание на базу данных создаст упрощенный пользовательский интерфейс, не дающий ничего, кроме CRUD пользовательского интерфейса Access. Вот почему Naked Objects (я один из ее коммиттеров) строит свою метамодель из модели предметной области pojo. Это позволяет пользовательскому интерфейсу отображать любые общедоступные методы в виде меню ... мы называем это «поведенчески завершенным».
Согласно комментарию о том, что пользовательский интерфейс не подходит для конечных пользователей, у меня есть два момента:
различать мощность пользователи против случайных пользователей. Большинство внутренних приложений предназначены для первых (для этого мы используем термин Алана Куперса «суверенное приложение»), которые понимают предметную область и не хотят, чтобы на их пути возникали причудливые элементы пользовательского интерфейса. Большинство внешних приложений, например общедоступные веб-сайты, предназначены для последних.
для последних есть ' Ничего подобного, чтобы помешать автоматически сгенерированному пользовательскому интерфейсу такого инструмента, как Naked Objects, заменить пользовательским или частично настроенным средством просмотра. Одним из таких средств просмотра является Scimpi, я также работаю над средством просмотра Eclipse RCP, которое будет отображать точки расширения. Но даже здесь пользовательский интерфейс autogen по-прежнему очень ценен для команды разработчиков и бизнес-аналитиков для исследования и создания прототипов.
Надеюсь, что некоторые из вышеперечисленного пробудили ваш интерес. Если вы хотите большего, погуглите или можете почитать мою книгу о доменно-ориентированном дизайне и НЕТ на pragprag.com.
HTH пользовательский интерфейс autogen по-прежнему очень ценен для команды разработчиков и бизнес-аналитиков при исследовании и создании прототипов.
Надеюсь, что некоторые из вышеперечисленного пробудили ваш интерес. Если вы хотите большего, погуглите или можете почитать мою книгу о доменно-ориентированном дизайне и НЕТ на pragprag.com.
HTH пользовательский интерфейс autogen по-прежнему очень ценен для команды разработчиков и бизнес-аналитиков при исследовании и создании прототипов.
Надеюсь, что некоторые из вышеперечисленного пробудили ваш интерес. Если вы хотите большего, погуглите или можете почитать мою книгу о доменно-ориентированном дизайне и НЕТ на pragprag.com.
HTH Дэн
Просто заметка о Java «проектах, реализующих эту идею» - tynamo - это новая версия инфраструктуры трасс