Методы для распределения значения между классами в программе

Question

Я использую

Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) + "\MyProgram"

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

Мне нужно убедиться, что:

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

Я считал:

• Делая это синглтоном
• Использование инжектора зависимости конструктора
• Использование внедрения зависимости свойств
• Использование АОП для создания пути, где это необходимо.

У каждого есть свои плюсы и минусы.

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

Я уже активно использую инъекцию конструктора в Касл Виндзор. Но это строка пути, и Windsor не очень корректно обрабатывает зависимости типа системы. Я всегда мог обернуть это в классе, но это кажется излишним для чего-то столь же простого, как передача значения строки. В любом случае этот маршрут добавил бы еще один аргумент конструктора для каждого класса, где он используется.

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

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

Есть ли другие варианты, которые я не рассматривал? Неужели я не согласен с оценкой вариантов, которые я рассмотрел?

Answer 1

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

MyAppEnvironment.ApplicationFolder

Если вы передаете значение при использовании инъекции, то вы либо а) создаете класс для хранения значения, либо б) передаете строку. Последнее плохо, потому что ваша ценность должна быть постоянной. Первый из них действителен, но, похоже, требует значительных накладных расходов, поскольку существует только одно допустимое значение (и вы все равно можете смоделировать / подделать это значение для тестов, если вам действительно нужно).

Полагаю, вы могли бы внедрить свой класс среды, но для меня это кажется излишним.

Answer 2

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

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

public static class GlobalSettings {
  private static string s_path;
  public static string Path { get { return s_path; } }
  public static void UpdatePath(string path) {
    if ( s_path != null || path == null ) { throw ... }
    s_path = path;
  }
}

Answer 3

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

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

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

Это метод, который я использовал в прошлом, и он хорошо мне послужил. Например, в одном приложении я воспользовался этим подходом, а затем обнаружил необходимость разрешить пользователю изменять настройки пути. Следуя этой архитектуре (и избегая одноэлементного), объекты, которые уже использовали путь, могли продолжать использовать старый без ошибок, но новый путь был использован правильно с точки изменения. Это просто сработало.

И классы могут быть перенесены в новый проект без зависимости от этой конкретной детали.

Answer 4

Мы бы добавили в конструктор класс типа IMyAppConfig, который является просто оберткой для всего этого.

Answer 5

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