Что Вы думаете о разработке для командной строки сначала?

инструменты Командной строки <забастовки> генерируют меньше событий тогда приложения для GUI и обычно проверяют все параметрические усилители перед запуском. Это ограничит Ваш gui, потому что для gui, могло иметь больше смысла просить параметрические усилители, поскольку Ваша программа работает или впоследствии.

, Если Вы не заботитесь о GUI тогда, не волнуются об этом. Если конечным результатом будет gui, сделайте gui сначала, то сделайте версию командной строки. Или Вы могли работать над обоими одновременно.

- Крупное редактирование -

После проведения некоторого времени на моем текущем проекте, я чувствую, как будто я совершил полный оборот из своего предыдущего ответа. Я думаю, что лучше сделать командную строку сначала и затем обернуть gui на нем. Если Вы должны, я думаю, что можно сделать большой gui впоследствии. Путем выполнения командной строки сначала, Вы свалили все аргументы сначала, таким образом, нет никаких неожиданностей (пока требования не изменяются) при выполнении UI/UX.

Существует несколько причин, почему, делая его этим путем не является хорошая идея. Многие из них были упомянуты, таким образом, я буду просто придерживаться одного отдельного момента.

инструменты Командной строки являются обычно не интерактивными вообще, в то время как GUI. Это - принципиальное различие. Это, например, болезненно для продолжительных задач.

Ваш инструмент командной строки в лучшем случае распечатает некоторую информацию о прогрессе - новые строки, текстовый индикатор выполнения, набор вывода... Любой вид ошибки это может только произвести к консоли.

Теперь Вы хотите хлопнуть GUI вдобавок ко всему, что Вы делаете? Проанализировать вывод своего продолжительного инструмента командной строки? Сканирование для ПРЕДУПРЕЖДЕНИЯ и ОШИБКИ в том выводе для подбрасывания диалогового окна?

В лучшем случае большая часть UI создала этот путь, подбрасывают пульсирующую занятую панель столько, сколько команда работает, затем покажите Вам диалоговое окно успешности или неуспешности, когда команда выходит. К сожалению, это - то, как много программ GUI UNIX брошено вместе, делая его ужасным пользовательским опытом.

Большинство repliers здесь корректно в высказывании, что необходимо, вероятно, абстрагировать фактическую функциональность программы в библиотеку, затем запишите интерфейс командной строки и GUI одновременно для него. Вся Ваша бизнес-логика должна быть в Вашей библиотеке и любом UI (да, командной строкой является UI), должен только сделать то, что необходимо для взаимодействия через интерфейс между бизнес-логикой и UI.

командной строкой А является слишком плохой UI, чтобы удостовериться, что Вы разрабатываете свою библиотеку, достаточно хорошую для использования GUI позже. Необходимо запустить с обоих с самого начала или запуститься с программирования GUI. Легко добавить интерфейс командной строки к библиотеке, разработанной для GUI, но это намного более твердо наоборот, точно из-за всех интерактивных функций, в которых GUI будет нуждаться (создание отчетов, прогресс, ошибочные диалоговые окна, i18n...)

В дополнение к тому, что сказанный Stu, имея общую библиотеку позволит Вам использовать его из веб-приложений также. Или даже от плагина IDE.

Сделайте программу, которую Вы представляете как веб-сервис. тогда сделайте gui и командную строку для вызова того же веб-сервиса. Этот подход также позволяет Вам делать сеть-gui, и также обеспечивать функциональность как SaaS партнерам по экстранет и/или лучше защищать бизнес-логику.

Это также позволяет Вашей программе более легко участвовать в SOA environement.

Для веб-сервиса, не идите за борт. сделайте yaml или xml-rpc. Сохраните его простым.

@Maudite

приложение командной строки проверит параметрические усилители впереди и GUI, не будет - но они будут все еще проверять тот же параметрические усилители и вводить их в некоторые универсальные функции рабочего.

Все еще та же цель. Я не вижу, что версия командной строки влияет на качество GUI один.

У John Gruber было хорошее сообщение о понятии добавления GUI к программе, не разработанной для одной: Брызги Ronco - На Удобстве использования

Сводка:Это не работает. если удобство использования не разработано в приложение с начала, добавив, что это позже - больше работы, чем кто-либо готов сделать.

Я не сделал бы этого по нескольким причинам.

Дизайн:

GUI А и CLI являются двумя различными интерфейсами, используемыми для доступа к конкретной реализации. Они обычно используются в различных целях (GUI для живого пользователя, к CLI обычно получают доступ путем сценариев), и может часто иметь различные требования. Связь двух вместе не является мудрым выбором и обязана вызвать Вас проблема в будущем.

Производительность:

способ, которым Вы описали вещи, необходимо породить исполняемый файл каждый раз, когда GUI нужно к d o что-то. Это просто ужасно.

правильный способ сделать это должно поместить реализацию в библиотеку, которой это называют и CLI и GUI.

Лучший подход мог бы быть должен разработать логику как lib с четко определенным API и, на этапе dev, никакой интерфейс (или твердый кодированный интерфейс) тогда, Вы можете мастер CLI или GUI позже

Своего рода зависит от Вашей цели для программы, но да я время от времени делаю это - это более быстро для кодирования, легче отладить, и легче записать быстрые и грязные тестовые сценарии для. И пока я структурирую свой код правильно, я могу возвратиться и лавировать на GUI позже без слишком большой работы.

тем, которые предполагают, что эта техника приведет к ужасному, неприменимому UIs: Вы правы. Запись утилиты командной строки является ужасным способом разработать GUI. Обратите внимание, все там думающие о записи UI, который не является , CLUI - не моделирует его как CLUI.

, Но, , если Вы пишете новый код, который самостоятельно не зависит от UI, затем пойдите для него.

Я обычно запускаю с библиотеки классов и отдельного, действительно дрянного и основного GUI. Поскольку Командная строка включает парсинг Командной строки, я чувствую, что добавляю много ненужных издержек.

В качестве награды, это дает подобный MVC подход, как весь "реальный" код находится в Библиотеке классов. Конечно, на более позднем этапе, Осуществляя рефакторинг библиотеку вместе с реальным GUI в один EXE также опция.

Я сделал точно это на одном инструменте, который я записал, и он работал отлично. Конечным результатом является scriptable инструмент, который может также использоваться через GUI.

я действительно соглашаюсь с чувством, что необходимо удостовериться, что GUI легок и интуитивен для использования, таким образом, могло бы быть мудро даже разработать обоих одновременно... немного функции командной строки, сопровождаемой оберткой GUI, чтобы гарантировать выполнение вещей интуитивно.

, Если Вы верны для реализации обоих одинаково, результатом является приложение, которое может использоваться автоматизированным способом, который я думаю, очень мощно для продвинутых пользователей.

@jcarrascal

, который я не вижу, почему это должно сделать GUI "плохо?"
Моя мысль была бы то, что это вынудит Вас думать о том, что "бизнес-" логика на самом деле должна выполнить, не вызывая беспокойство слишком много о вещах, являющихся симпатичным. Как только Вы знаете то, что это должен/может, делают, можно создать интерфейс вокруг этого любым способом имеет большую часть смысла.

примечание Стороны: Не запустить отдельную тему, но что предпочтительный путь состоит в том, чтобы обратиться к ответам на Ваши вопросы? Я рассмотрел и это и редактирование самого вопроса.

Если Вы планируете сохранить свою версию командной строки Вашего приложения тогда, я не вижу проблемы с выполнением его этот путь - это не потраченное впустую время. Вы все еще закончите тем, что кодировали основную функциональность своего приложения для командной строки и таким образом, у Вас будет большой блок работы сделанным.

я не вижу прокладывание себе путь, как являющееся барьером для хорошего UI - Вы все еще добрались, время, чтобы добавить один и сделать применимо и т.д.

, я предполагаю, что этот способ работать только действительно работал бы, если Вы намереваетесь для своего законченного приложения иметь и командную строку и варианты GUI. Достаточно легко дразнить UI и встроить Вашу функциональность в это и затем украсить UI позже.

Соглашаются с Stu: Ваша базовая функциональность должна быть в библиотеке, которую называют от кода GUI и командной строки. Вызов исполняемого файла от UI ненужный служебный во времени выполнения.

Вероятно, лучше начать с командной строки сначала удостоверяться, что у Вас есть корректная функциональность. Если Ваши основные пользователи не могут (или не быть), используют командную строку тогда, можно добавить GUI сверх работы.

Это сделает Ваше приложение лучше удовлетворенным для сценариев, а также ограничения суммы первичных Bikeshedding, таким образом, можно будет добраться до фактического решения быстрее.

Я думаю, что это зависит от того, какое приложение Вы разрабатываете. Разработка для командной строки помещает Вас на кратчайший путь к тому, что Alan Cooper называет "Моделью Реализации" в , Обитатели Выполняют Убежище . Результатом является пользовательский интерфейс, который является неинтуитивным и трудным использовать.

37signals также рекомендует разрабатывать Ваш пользовательский интерфейс сначала в Получение реального . Помните, во всех отношениях, в большинстве приложений, пользовательский интерфейс программа. Код бэкэнда должен просто там поддерживать его.

Моя техника для программирования внутренней функциональности сначала, не имея потребности в явном UI (особенно, когда UI еще не является моим заданием, например, я - desigining веб-приложение, которое находится все еще в стадии проектирования) должна записать модульные тесты.

Тот способ, которым я не должен даже писать консольное приложение для насмешки вывода моего кода бэкенда - это - все в тестах, и в отличие от консольного приложения я не должен бросать код для тестов далеко, потому что они все еще полезны позже.

Joel написал статью, контрастирующую этот ("стиль Unix") разработка к GUI, первому ("стиль Windows") метод несколько лет назад. Он назвал его Biculturalism.

я думаю в Windows, станет нормально (если это уже не будет иметь) обертывать Вашу логику в блоки.NET, к которым можно тогда получить доступ и от GUI и от поставщика PowerShell. Тем путем Вы получаете лучший из обоих миров.

Поместите общую функциональность в библиотеку, затем запишите командную строку и фронтенд GUI для нее. Тем путем Ваш переход слоя не связывается с командной строкой.

(Кроме того, этот путь добавляет другую проблему безопасности: GUI не придется сначала удостовериться, что это - ПРАВИЛЬНЫЙ todo.exe, который называют?)

Если Вы делаете свою разработку правильно, то должно быть относительно легко переключиться на GUI позже в проекте. Проблема состоит в том, что довольно трудно разобраться в нем.