Ищу руководство высокого уровня по структурированию ac # dll

Question

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

В частности, я хочу создать dll, которая содержит код для анализа длинной строки форматированного текста в структурированные данные некоторого вида. У меня есть необходимые рецепты регулярных выражений, подготовленные для получения данных уже. Большинство полей будут отдельными значениями, но потенциально может быть отношение один ко многим. Сколько классов я должен иметь и каковы их роли? Где происходит фактический синтаксический анализ и какой объект я должен возвращать?

Я в недоумении относительно того, как действовать, пока не узнаю, какой тип описываю.

Answer 1

Сначала подумайте о приложении в 3 слоя. Во-первых, это слой данных или персистентности, это может быть база данных, XML-файлы или любые другие данные ввода / вывода. Второй - это домен или бизнес-уровень, где применяются фактическая логика и бизнес-операции. Наконец, слой представления, это может быть приложение для Windows, веб-сайт и т. Д.

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

Старайтесь, чтобы каждый слой был максимально отделен от остальных. Используйте слабосвязанные интерфейсы, где требуется связь между ними. Например, уровень домена может определять набор интерфейсов (или контрактов), точно определяющих, что ему нужно / что нужно получить от уровня домена (например, используя комбинацию шаблона хранилища и шаблона DTO). Точно так же уровень представления должен определять контракт именно для того, что ему нужно / что он ожидает получить от уровня домена, хорошим примером этого является VM-часть шаблона MVVM.

Уровень домена часто выступает в качестве посредника между уровнями данных и представления, сопоставляя уникальный способ представления бизнес-данных каждым уровнем. Ни на каком этапе уровень представления не должен знать об уровне данных или наоборот.

Answer 2

Если вы не уверены, как структурировать ваши объекты, взгляните на Принципы ООП ТВЕРДЫЕ Это основа основ.

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

Честно говоря, будьте готовы переписывать снова и снова, если хотите стать великим программистом. Вот так все учатся:).

Что бы вы ни делали, не трогайте статические методы. Они злые.