Долго следовал советам о том, что static — это неправильно.

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

Хотелось-бы услышать аргументированные личным опытом мнения — как лучше делать и, главное, почему ?

Поясню почему мне хочется сделать доступ отовсюду.

На первоначальном этапе разницы нет, однако, со временем, при требованиях "улучшить функционал путем добавления новой фичи быстро" часто происходит такая ситуация:

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

При этом физическая сущность данных — одна и, соответственно, более одного рабочего экземпляра объекта-хранилища данных — не будет.

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>хочется сделать хранилище данных слоя бизнес-логики как static
Кмк, формулировка вопроса некорректна. Хранилище данных имеет мало отношения к слою бизнес-логики. Это — слой доступа к данным. В идеале, реализации хранилища могут быть разные, например, для целей тестирования.

N_P>с доступом из любого места приложения
Используйте паттерн service locator с каким-нибудь IoC-контейнером и получайте IMyDataService через него в любом месте приложения.

Здравствуйте, Nikolay_P_I, Вы писали:

N_P>Но с опытом всё больше хочется сделать хранилище данных слоя бизнес-логики как static — с доступом из любого места приложения.

«Доступ из любого места», «единственность экземпляра» и «static» — это вещи независимые.

N_P>При этом физическая сущность данных — одна и, соответственно, более одного рабочего экземпляра объекта-хранилища данных — не будет.

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

Здравствуйте, HowardLovekraft, Вы писали:

N_P>>с доступом из любого места приложения
HL>Используйте паттерн service locator с каким-нибудь IoC-контейнером и получайте IMyDataService через него в любом месте приложения.

Дык ведь тогда static-ом или синглтоном придётся делать сам контейнер.
А ещё бывает так, что в рамках одного процесса необходимо работать с несколькими однотипными сервисами, но связанными с разными источниками данных. Тут уже и не всякий IoC поможет.

Здравствуйте, baranovda, Вы писали:

B>Дык ведь тогда static-ом или синглтоном придётся делать сам контейнер.
Почему?
Псевдо-код, в котором объект получает ссылку на реализацию сервиса с использованием MEF:

[Export(typeof(IBLLModule))]
public class MyBLLModule
{
  [ImportingConstructor]
  public MyBLLModule(IDataService dataService)
  {
    this.dataService = dataService;
    ...
  }
}

Нет тут никакого обращения к статическому классу или синглтону. Ну да, где-то там при инициализации приложения создан контейнер. Но с чего он static или singleton?

B>А ещё бывает так, что в рамках одного процесса необходимо работать с несколькими однотипными сервисами, но связанными с разными источниками данных
На каком-то этапе абстракция от источника данных заканчивается и нужно знать, куда писАть/откуда читать. Вопрос в создании правильных экземпляров сервисов и в логике обращения к ним. В чем проблема-то?

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, baranovda, Вы писали:

B>>Дык ведь тогда static-ом или синглтоном придётся делать сам контейнер.
HL>Почему?
HL>Псевдо-код, в котором объект получает ссылку на реализацию сервиса с использованием MEF:
HL>

HL>[Export(typeof(IBLLModule))]
HL>public class MyBLLModule
HL>{
HL>  [ImportingConstructor]
HL>  public MyBLLModule(IDataService dataService)
HL>  {
HL>    this.dataService = dataService;
HL>    ...
HL>  }
HL>}
HL>

HL>Нет тут никакого обращения к статическому классу или синглтону. Ну да, где-то там при инициализации приложения создан контейнер. Но с чего он static или singleton?

С MEF не работал и ни о чем не спорю, просто интересно — ведь в вышеприведённом фрагменте для создания экземпляра MyBLLModule нужно где-то выполнить код типа:

IBLLModule pModule = ЧтоТо.Resolve<IBBLModule>();

Вот это ЧтоТо — оно откуда берётся и где инициализируется?

Здравствуйте, baranovda, Вы писали:

B>в вышеприведённом фрагменте для создания экземпляра MyBLLModule нужно где-то выполнить код типа:
Не обязательно. При создании экземпляров через MEF-контейнер реализации IBLLModule могут так же импортироваться с помощью атрибутов, без явного обращения к контейнеру.

B>Вот это ЧтоТо — оно откуда берётся и где инициализируется?
Экземпляр контейнера, конечно, создается один раз. Но это не значит, что он — синглтон.
Для примера можно глянуть на код MefBootstrapper из Prism. В нем создается контейнер, через который разрешаются зависимости модулей, создаваемых в приложении.