Как хранить/обрабатывать данные, доступные другим классам в C#

Question

Я пишу программу САПР. Предположим, что у меня есть класс ввода, этот класс читает различные данные из текстового файла и создает множество списков/словарей и ... Эти данные должны быть доступны другими методами в других классах, которые необходимо изменить. Теперь вот как я это сделал:

У меня есть один статический класс: Building.cs Когда я создаю/или загружаю проект, этот класс содержит все данные, такие как список столбцов, балок, точек и т. Д. Все эти хранятся как частные поля. Я могу получить доступ к ним с помощью общедоступных методов класса, таких как GetColumns или GetPoints ...

Теперь у меня также есть нестатические классы. Они содержат 2-3 общедоступных метода. и сделать некоторые вещи на различных частях здания.

public static class Building 
{ 
    private static List<Column> columns; 
    private static List<Beams> beams; 
    private static List<Points> points; 

    public static List<Column> GetColumns() 
    { 
     return Columns; 
    } 
} 

public class ColumnsService() 
{ 
    private List<Columns> columns; 
    public GroupColumns(List<Columns> columns) 
    { 
     this.columns = columns; 
    } 

    public void Group() 
    { 
     // group columns 
    } 
} 

var columns = Building.GetColumns(); 
var columnsService = new ColumnsService(columns); 
columnsService.Group(); 

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

Answer 1

Что, семантически, является Building?

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

Если это так, то мне кажется неинтересным сделать это static. Если их несколько, это должна быть модель экземпляра. Он будет содержать атрибуты, которые описывают его, и операции, которые взаимодействуют с ним. При моделировании бизнес-домена следует управлять структурой этого объекта до того, как будет рассмотрено, как другие объекты будут взаимодействовать с ним.

Итак, давайте предположим, что мы делаем его экземпляром модели:

public class Building 
{ 
    // attributes and operations 
} 

Тогда, как вы спрашиваете, как другие объекты взаимодействуют с ним?

Зависит от взаимодействия.

Предположим, что объект должен «визуализировать» здание каким-то образом. Назовем это BuildingPrinter из-за отсутствия лучшего термина. Очевидно, для «печати» требуется Building. Поэтому для этого требуется одно:

public class BuildingPrinter 
{ 
    public void Print(Building building) 
    { 
     // implementation 
    } 
} 

Возможно, у вас есть объект, который каким-то образом «обертывает» здание. Что-то, что не может существовать без здания, независимо от выполненных операций. Я не могу придумать один для этого конкретного бизнес-домена, поэтому давайте просто назовите его BuildingWidget. Так как она нуждается в здание, чтобы существовать, она требует одного:

public class BuildingWidget 
{ 
    private Building currentBuilding; 

    private BuildingWidget() { } 

    public BuildingWidget(Building building) 
    { 
     currentBuilding = building; 
    } 
} 

Дело в том, с точки зрения моделей, построить общий домен, если требуется что-то, то оно должно подаваться. Модели не должны выходить в какой-либо глобальный хранилище данных, тесно связанный с этим хранилищем данных, чтобы получить то, что им нужно. Это называется принципом инверсии зависимостей.

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

Два общих шаблона должны иметь статическую фабрику или репозиторий. Например:

public class BuildingFactory 
{ 
    public static Building FetchBuilding(int buildingId) 
    { 
     // implementation 
    } 
} 

Этот завод может иметь статический кэшируются строительный объект. Само здание не является статическим, но по соображениям производительности экземпляр его кэшируется статически, так что он не постоянно повторно загружается из хранилища данных поддержки (например, базы данных). Вы также можете добавить методы для отмены кэша и повторной выборки или инкапсулировать эту логику на завод (например, всегда повторно извлекать через 5 минут или после 10 обращений или какое-либо другое правило). (За кулисами, этот завод может даже использовать хранилище, как показано ниже, для повторного получения этого экземпляра. В этом случае, вы уже догадались, BuildingRepository потребовалось бы на BuildingFactory конструктора.)

Этот завод объект может также отвечают за , создавая здание, основанное на некоторых спецификациях, если, например, у вас есть причина сделать конструктор Building закрытым.

Или, повторно выборки из данных, рассмотрим хранилищу:

public class BuildingRepository 
{ 
    public Building GetBuilding(int buildingId) 
    { 
     // fetch from database 
    } 

    public Building SaveBuilding(Building building) 
    { 
     // save to database, return updated version 
    } 
} 

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