Есть ли веская причина писать код в Program.cs/main, а не использовать классы?

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

Один из них касается консольных приложений. Эти приложения переносятся на С# из сценариев оболочки. Некоторые из этих сценариев достаточно большие (300-400 строк кода после преобразования) и делают такие вещи, как ввод-вывод, доступ к электронной почте и базе данных.

Для каждого из этих сценариев я создал класс. Каждый класс имеет метод Run, который вызывает любые методы/операции, которые находятся внутри. Внутри Program.cs/main я создаю объект указанного класса и вызываю Run. Program.cs содержит 4-5 строк кода. Чистый и простой.

Мой технический руководитель хочет избавиться от классов script и просто иметь все внутри основного метода program.cs. Его рассуждение состоит в том, что это слишком запутанно, как оно есть.

Чувствовать себя неудобно, так как класс больше не может быть повторно использован/упакован в библиотеку классов без необходимости возиться с основным методом.

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

Спасибо за ваше время.

Ответ 1

Чувствуется неудобным делать это таким образом, поскольку класс больше не может быть повторно использован/доступен для пакетов в библиотеке классов, не имея необходимости возиться с основным методом.

Это не должно быть так.

Например, каждый из ваших сценариев может иметь ту же структуру, что и он, но также имеет метод private static void Main(string[] args). (Это может быть не частным, если вы хотите - все зависит от ваших потребностей.)

Таким образом, он является автономным (может быть скомпилирован как один вход для одного вывода, а затем запущен), который иногда может быть удобным, но может также использоваться как часть библиотеки классов. Наличие метода Main никоим образом не предотвращает использование класса из других классов.

Не понятно, есть ли у вас один файл Program.cs или один на script. Если у вас есть один за script, каждый из которых имеет всего 4-5 строк, это кажется несколько бессмысленным.

Теперь это было бы не так, как я обычно структурировал большое приложение, но если точка состоит в том, чтобы иметь несколько "скриптов", каждый из которых можно запустить автономно, то предоставление каждому классу метода Main doesn ' t кажется слишком плохим.

Фактически, то, что я часто делаю для демонстрационных целей, имеет несколько классов с методами Main в одном проекте, а затем имеет отдельную точку входа (которая находится в Program.cs), которая использует отражение, чтобы найти все остальные и затем позволяет пользователю/ведущему выбрать, какой из них выполнить.

Если весь ваш код имеет смысл иметь в одном классе, то наличие крошечного дополнительного метода ввода не кажется такой проблемой. Если на самом деле это случай слишком большого кода для одного класса, независимо от того, где находится точка входа, это другой вопрос. (Итак, если вы придерживаетесь единственного ScriptClass, когда на самом деле вы должны давать разные задачи для разных классов, это тоже плохо). Точно так же, если он действительно настаивает на том, что весь код находится в одном методе, это определенно проблема для тестирования и ремонтопригодности.

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

Ответ 2

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

Вы заявляете, что модульность и переупаковка во внешнюю библиотеку - это то, что вам нужно сделать - я бы встретил "почему?". (это то, что я подразумеваю под дополнительной работой).

Если вы создаете простой набор методов в одном файле - это один файл! Это, по определению, будет легче работать с несколькими проектами и т.д.

Тем не менее, нам трудно понять, о чем мы говорим, если нет более подробной информации. Если он "отправляет ночной отчет и посылает по электронной почте этих людей" - да, что-то, что не требует библиотеки классов и тонны модульности. Запустите метод, и все готово.

Ответ 3

Вы знаете, что точка входа консольного приложения настраивается, правильно?

Мой предпочтительный метод:

class MeaningfullyNamedProgram { 
    public static void Main(string[] args) {
        var program = new MeaningfullyNamedProgram(args);
        program.Run();
    }

    public MeaningfullyNamedProgram(string[] args) { 
    }

    public Run() {
        // well structured, broken-out code follows 
    }
}

Направьте точку входа проекта с помощью значащегоNamedProgram.Main

ПРИМЕЧАНИЕ. Я оставлю это как упражнение для читателя, но вы можете создать для него базовый класс с использованием дженериков и сохранить себе некоторую типизацию.

Ответ 4

Ваш технический руководитель нуждается в хорошем разговоре! Ввод всего в Program.cs - это не путь вперед.

Ответ 5

Ну, его путь концептуально проще, поскольку он как программы были написаны до того, как была изобретена подпрограмма....

Ваш путь лучше: он поддерживает повторное использование и будет легче модифицировать и отлаживать.

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

Ответ 6

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

Ответ 7

Разделение логики на отдельный класс (или классы) - это путь. Включение всего этого в одно место нарушает принципы дизайна SOLID и DRY. Вы наверняка на правильном пути с вашим подходом.

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

Ответ 8

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