Отделение данных от кода пользовательского интерфейса с помощью сущностей Linq to SQL

Question

Если важно сохранить доступ к данным «подальше» от бизнес-уровня и уровня представления, какие альтернативы или подходы я могу использовать, чтобы мои сущности LINQ to SQL могли оставаться на уровне доступа к данным?

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

Например, в моей базе данных есть таблица с именем Books.Если пользователь создает новую книгу с помощью пользовательского интерфейса, класс Book, сгенерированный sqlmetal, кажется идеально подходящим, хотя я так тесно связываю свой дизайн.

Answer 1

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

Если вы делаете дублирование 1: 1 сущностей, предлагаемых linq для sql, то это может означать, что их не стоит иметь там, потому что вы все еще так же привязаны к этим классам, как и к сущностям предлагается linq к sql.

Создавая еще один слой, вы также исключаете преимущества отслеживания изменений, предоставляемые linq to sql, а это означает, что вы должны копировать любые изменения из ваших классов в сущности, предоставленные linq to sql, для выполнения операций с данными.

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

Вы можете рассмотреть возможность проецирования данных в другой класс в интересах вашей презентации (модель представления) или бизнес-логики. Это путь, по которому я склонен идти, если я хочу использовать linq to sql, но мне не нужно отображение 1: 1 между сущностями и моими моделями представления.

Answer 2

Что я делаю, так это чтобы все мои DataAccess (LINQ-to-SQL в вашем случае) были в одном проекте, а затем у меня есть другой бизнес-проект, который использует проект DataAccess, тем самым разделяя проект DataAccess с уровня пользовательского интерфейса.

В вашем примере с книгами у моего бизнес-уровня будет класс Book:

public class Book
{

    private IAuthorRespository _authorRepository = new LinqToSqlAuthorRepository();
    private IBookRespository _bookRepository = new LinqToSqlBookRepository();

    public int BookId { get { return _bookId; }}
    private int _bookId;

    public virtual string BookName{get;set;}
    public virtual string ISBN {get;set;}
    // ...Other properties

    public Book()
    {
        // When creating a new book
        _bookId = 0;
    }

    public Book(int id)
    {
        // For an existing book
        _bookId = id;
        Load();
    }

    protected void Load()
    {
        BookEntity book = _bookRepository.GetBook(BookId);
        BookName = book.BookName;
        ISBN = book.ISBN;
    }

    public void Save()
    {
        BookEntity book = MapEntityFromThisClass();
        _bookRepository.Save(book);
    }

    public Author GetAuthor()
    {
        return _authorRepository.GetAuthor();
    }

}

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

Вы можете разделить это далее, используя IoC с такой системой, как Microsoft Unity или Castle, чтобы вам не приходилось писать = new LinqToSqlXYZ();, и вместо этого вы можете написать что-то вроде IoC.Resolve<IBookRepostory>(); (в зависимости от вашей реализации ). Это означает, что ваш класс Book больше не привязан к LINQ-to-SQL.