Преобразование нескольких классов VFP9 в C#

Question

Позвольте мне начать с того, что я не программировал на языке программирования с большим количеством ОО, начиная с Java в колледже (я закончил в декабре 2005 года). С тех пор как я закончил, я программировал с FoxPro 2.5 - VFP9. Теперь компания, в которой я работаю, стремится конвертировать все наши приложения FoxPro в C#.

Моя часть этого проекта - преобразование нашего приложения для анализа отчетов. В VFP9 он состоит из 5-6 форм (ни одна из которых не будет перенесена, так как мы создали новый интерфейс C# для его замены), одного базового класса, который содержит все наши стандартные методы, и приблизительно 575 отдельных классов синтаксического анализатора. (некоторые из которых ничего не делают, кроме как устанавливают несколько переменных / свойств, специфичных для синтаксического анализатора, и вызывают необходимые базовые классы). Некоторые из синтаксических анализаторов содержат свои собственные пользовательские методы, которые все еще используют базовые методы и глобальные свойства и взаимодействуют с ними.

Теперь на мой вопрос...

С точки зрения дизайна, мы бы хотели, чтобы наш новый интерфейс C# порождал несколько исполняемых файлов (3-5 EXE), которые будут вызывать наши новые библиотеки классов C# base/parser (DLL). Первоначально я думал, что у меня будет одно решение / проект с Base_Code.cs и другими 575 файлами parser.cs (H1.cs, H2.cs, H3.cs и т. Д.). Однако нам нужна возможность создавать каждый файл.cs независимо от других, поскольку я могу обновлять Base_Code.cs, пока мой сотрудник обновляет H1.cs.

Как мне лучше структурировать это? Оставляю ли я одно решение, но создаю 576 проектов, или я создаю 576 решений, использующих то же пространство имен, что и другая команда, пытающаяся в настоящее время?

Существует несколько глобальных переменных / свойств, которые мы используем в базовом коде, и каждый синтаксический анализатор (они будут переданы из внешнего приложения), такие как пути к файлам, имена файлов и т. Д., Которые будут статическими, поэтому их необходимо учитывать рассмотрение также, думая о дизайне.

РЕДАКТИРОВАТЬ ДЛЯ ПРИМЕРА **

Внешний интерфейс C# - это система очередей и средство просмотра файлов / состояний. Этот интерфейс "ставит в очередь" отчеты, которые мы собираем в течение дня. Отчет в верхней части списка определяет, какая DLL понадобится. Внешнее приложение и библиотеки DLL полностью отделены друг от друга.

Пример: H00001_2342318.MSG - это вызовет DLL H00001 H00002_3422551.MSG - это вызовет DLL H00002

Каждый H00001, H00002 и т. Д. (Всего 575 DLL) будет использовать методы, которые есть в BASE DLL.

Если мне нужно обновить DLL H00001, мне нужно сделать это без необходимости перестраивать все 575 DLL.

Answer 1

Похоже, что вы хотите, это "плагин" вид архитектуры. Это позволяет вам вставлять / обновлять dll (сборки) без перекомпиляции основного приложения.

Например, http://code.msdn.microsoft.com/windowsdesktop/Creating-a-simple-plugin-b6174b62

и связанные.

Answer 2

576 проектов и / или решений - это кошмар обслуживания. У меня гораздо меньше (75 или около того) проектов по менее чем дюжине решений для всего набора продуктов. Это включает в себя тесты, компоненты инфраструктуры и т. Д., И единственный способ, которым я придерживаюсь этого, - это строгие соглашения об именах / путях, контроль исходного кода и сценарии для автоматизации.

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

Я бы начал с одного решения с логически разделенными проектами (например, разбил все по функциям / зависимостям и добавил тестовый проект для каждой библиотеки).

Контроль исходного кода устраняет любые опасения по поводу конфликтов между членами команды. Если у вас возникли внутренние проблемы с настройкой и управлением исходным кодом, обратитесь к Team Foundation Services Online: http://tfs.visualstudio.com/. Установка невероятно проста и бесплатна для 5 пользователей.

Если вам в конечном итоге понадобится большее разъединение между проектами, вы можете рассмотреть возможность использования пакетов NuGet с локальным репозиторием для изоляции / версии различных, отдельных компонентов. Это не будет моим первым шагом, но стоит помнить об этом.

Судя по комментариям, вы выполняете ежедневное развертывание автономных подразделений.

1. Это кажется рискованным. Может ли это быть обусловлено конфигурацией / данными, а не изменениями кода?

2. 576 полностью автономных единиц кажется проблемой при разработке приложений (например, повторное использование?)

3. Предполагая, что новый код должен развертываться каждый день, возможно, язык сценариев + DLR мог бы сделать это проще. Динамическая компиляция C# также возможна.