Шаблон OOP/Repository: создание слишком большого количества объектов для разных подмножеств доступа к базе данных?

Question

Я портирую старый код VB6 (да да, VB6 ...) на C#. Я рефакторинг кода, чтобы быть более объектно-ориентированным, и, среди прочего, я реализую классы репозитория для доступа к базе данных.

Теперь эти классы репозитория возвращают объекты, а не наборы данных. Но я считаю, что иногда я возвращаю только часть информации, которую может содержать объект. Пример. Я могу получить полный список документов с именем, файловым путем, папкой, создателем и т. Д. - или я могу получить результаты поиска документов, которые содержат только имя и папку.

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

Answer 1

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

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

Создайте схему поддонов для своих объектов, чтобы они не становились слишком сложными. Я думаю, что нужно, чтобы объект для объекта рассматривался для репозитория. Опять же, создание пользовательских объектов или DTO могло бы создать ненужный код и сложность. Для целостности держите свои объекты с заполненными полями и другими, которые не нужны в этом подмножестве нуль, таким образом, если эта информация будет запрошена позже, информация может быть возвращена обратно, это значение не существует для определенного объекта.

Вот краткий пример, попробуйте использовать классы POCO с каркасом сущности.

public interface IRepository<TEntity, in TKey> where TEntity : class 
{ 
    TEntity Get(TKey id); 
} 

public class SomeRepo1 : IRepository 
{ 
    private readonly FileDbContext someDbContext; 

    public FileRepository(FileDbContext dbContext) 
    { 
     someDbContext = dbContext; 
    } 

    public File Get(string id) 
    { 
    return someDbContext.Files.ToList(); 
    } 
} 

Пример POCO класс, которые могут быть использованы для файлов:

public class File 
{ 
    public int Id { get; set; } 
    public string FileName { get; set; } 

} 
public class Folder 
    { 
    public List<File> Files { get; set; } 

    } 

Подробнее здесь: https://msdn.microsoft.com/en-us/library/ff649690.aspx

Надеется, что это помогает!

Answer 2

Но я считаю, что иногда я возвращаю только часть информации, которую может содержать объект.

Вы только что смутили модель объекта с помощью модели сохранения.

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

Итак, что-то похожее на «подмножество» с точки зрения вашего хранилища, возможно, не может быть «подмножеством» с точки зрения объектной модели.

В качестве примера конкретного решения Entity Framework 6 включает в себя так называемые Таблица Расщепление, который позволяет разделить класс модели на два класса, класс с основными свойствами, которые всегда загружаются и еще один класс со вспомогательными свойствами, которые лениво загружаются только когда вы ссылаетесь на виртуальное свойство основного класса.

Пример учебник: http://www.c-sharpcorner.com/UploadFile/ff2f08/table-splitting-in-entity-framework-6-code-first-approach/

(просто говоря, наоборот, где две физических таблицы отображаются в класс модели ого называются Entity расщепление)