Парсинг usercontent в репозиторий. Какой подход лучше?


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

Мой проект принимает различные пользовательские файлы в качестве входных данных и преобразует их в хранилище объектов для удобства использования.

Например:

Userfile A with the content: 
"id:a" - "value1:contentA1" - "value2:contentB1" 
"id:b" - "value1:contentA2" - "value2:contentB2" 
"id:c" - "value1:contentA3" - "value2:contentB3"

Теперь я вижу два разных подхода к разбору этого файла на объекты (что лучше?):

1)

Мы получили класс сущностей:

public class UserContent
{
    public int ID { get; set; }
    public string Value1 { get; set; }
    public string Value2 { get; set; }
}

Услуга, которая занимает строку пользовательский файл и анализирует его в объект:

public class UserContentParser
{
    public UserContent ParseUserContent(string content)
    {
        // ...
        // splitting the content
        // ...
        return new UserContent
                            { 
                                ID = id,
                                Value1 = value1,
                                Value2 = value2
                            };
    }
}

Парсеконтроллер:

public class ParseController
{
    private Repository _repository = new Repository();
    private UserContentParser _userContentParser = new UserContentParser();

    public Repository StartParsing(File userFile)
    {
        // ...
        // reading file
        // ...
        foreach(var contentLine in userFileContent)
        {
            _repository.AddUserContent(_userContentParser.ParseUserContent(contentLine));
        }
    }
}

Другой подход, который я вижу, заключается в следующем:

2) Этот подход просто состоит из двух классов (без класса обслуживания):

public class UserContent
{
    public UserContent(string content)
    {
        // ...
        // splitting the content
        // ...
        ID = id;
        Value1 = value1;
        Value2 = value2;
    }

    public int ID { get; set; }
    public string Value1 { get; set; }
    public string Value2 { get; set; }
}

public class ParseController
{
    private Repository _repository = new Repository();
    private UserContentParser _userContentParser = new UserContentParser();

    public Repository StartParsing(File userFile)
    {
        // ...
        // reading file
        // ...
        foreach(var contentLine in userFileContent)
        {
            _repository.NewUserContent(contentLine);
            // in this method the repository creates the 
            // new UserContent(contentLine)
        }
    }
}

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

Какой подход здесь лучше? Может быть, есть лучшая альтернатива? И что произойдет, если другие зависимости будут нужно было разобрать пользовательский контент? Нормально ли, если сущность зависит от служб, или лучше не иметь зависимостей в объектах сущности? И еще один вопрос, Является ли класс UserContent DTO, потому что он используется для разбора пользовательского контента в нем и передачи его другим плагинам?

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

С уважением, Геррит

1 4

1 ответ:

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

Однако, в качестве общего совета вы должны следовать SRP и поместить каждую ответственность в свой собственный класс, поэтому иметь парсер как отдельный класс имеет смысл. Имея это в отдельном классе позволит вам извлечь Parser интерфейс от него и иметь несколько реализаций и управлять зависимостями парсера, если вы когда-нибудь доберетесь до этого.

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