Архитектурные соображения при разработке консольных приложений?

Question

Недавно я запрограммировал консольное приложение и испытал много трудностей при его разработке во многих аспектах, особенно на C#, учитывая его чистую объектно-ориентированную парадигму.Вопросы, с которыми я столкнулся, включают в себя что угодно: от того, как передать параметры до того, как вернуть проблемы в класс точки входа, а также многие, многие другие.

Мой вопрос:Может ли кто-нибудь из вас знать хорошие проекты консольных приложений в объектно-ориентированной парадигме, чтобы я мог учиться у них?Код хороших реализаций: особенно добро пожаловать.

РЕДАКТИРОВАТЬ: Мне не нужны API командной строки, а хорошие принципы проектирования и, в частности, хорошие реализации, на которых я мог бы поучиться.

РЕДАКТИРОВАТЬ 2: В приложении есть простое взаимодействие с пользователем, но это не полноценная разновидность CLI/REPL.Думайте об этом как о команде TeX, более или менее.Интересно, что даже несмотря на то, что существует хорошая теория (не отличающаяся от X, используйте шаблон Y, вы должны знать принципы ООП... [ваш профессор информатики был бы так горд!]), реального кода, который я мог бы взять на вооружение, не существует. посмотрите, чтобы увидеть эти концепции в действии.Опять же, где мне искать (код!) хорошее приложение командной строки в чисто объектно-ориентированной парадигме?

Answer 1

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

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

Разумно думать о приложении как о наборе отличных " команд " объекты, по одному для каждого типа операции. Таким образом, точка входа в приложение должна быть своего рода объектом CommandLineDispatcher, который отправляет запросы в соответствующий объект Command.

Чтобы быть модульным, диспетчер должен быть настроен с абстрактным отображением (например, Hashtable), чтобы связать каждый токен команды (обычно первое слово строки командной строки) с объектом Command, который его обрабатывает. Диспетчер также может обрабатывать общие параметры, возможно, используя некоторые готовые «getopts». библиотека для тяжелой работы.

Для начала, каждый объект Command может реализовывать согласованный интерфейс для выполнения своей работы; может быть что-то вроде этого:

public void execute(List<String> args)

Таким образом, диспетчер точки входа просто находит запрашиваемую Команду и выполняет ее.

Что касается обработки ошибок: метод execute () может просто генерировать исключение для сообщения об ошибках ... Исключение может быть перехвачено и обработано диспетчером или просто зарегистрировано на экране. В качестве альтернативы, сбой Команды может вызвать некоторую общую функцию using для объединения сообщения об ошибке с общими инструкциями. Я не думаю, что "точка входа" обязательно должны быть осведомлены о проблемах, как вы предлагаете; если вам нужна надежная обработка ошибок (например, для ведения журнала или оповещения), похоже, что он принадлежит отдельному компоненту, который может быть предоставлен объекту Command.

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

Answer 2

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

Сказав это, не могли бы вы подробно рассказать о нашем вопросе о том, где они находятся в ключевых областях?

Вы можете использовать множество шаблонов из Руководства по архитектуре приложений от Microsoft.

Answer 3

В Java я часто использую CLI Apache , я нашел Google CLI для .NET ; но это, похоже, еще не реализовано. Может быть, вам полезно прочитать подход Java для получения параметров консоли.

Для архитектуры вашего приложения она не должна сильно отличаться от архитектуры, которую вы будете использовать в веб-приложении, разница в том, что консоль - это интерфейс уровня презентации. Может быть, вы можете определить некоторые 'ConsoleControllers' для получения модели с бизнес-уровня на консоль и наоборот. Думайте о каждом вводе пользователя как о запросе;).

Answer 4

В самом (крайнем) общем смысле консольное приложение представляет собой разновидность REPL:

http://en.wikipedia.org/wiki/REPL

Очевидно, что предметно-ориентированное (консольное) приложение не поддерживает полный по Тьюрингу язык, но многие проблемы совпадают, и хороший REPL должен быть очень надежным приложением командной строки.Я уверен, что вы сможете многому научиться, изучая проектирование и реализацию типичного REPL.(Большинство REPL имеют открытый исходный код.(Попробуйте Ruby или Python для объектно-ориентированных REPL))

Answer 5

Чтобы программа имела хороший архитектурный дизайн, особенно в C #, вы должны быть знакомы с концепциями ОО-проектирования, чтобы в полной мере воспользоваться преимуществами ОО-парадигм