2010-06-14 31 views
1

如果讓數據訪問遠離業務層和表示層非常重要,那麼我可以採取哪些替代方法或方法,以便我的LINQ to SQL實體可以保留在數據訪問層?從LINQ到SQL實體的UI代碼中分離數據

到目前爲止,我似乎只是簡單地複製sqlmetal生成的類,並傳遞這些對象,而不是簡單地保留兩個appart。

例如,我在我的數據庫中有一張名爲Books的表格。如果用戶通過UI創建新書,由sqlmetal生成的Book類看起來像是一個完美的適合,儘管我通過這樣做來緊密耦合我的設計。

回答

0

我所做的是在一個項目中使用我的所有DataAccess(您的案例中的LINQ到SQL),然後我有另一個使用DataAccess項目的業務項目,從而將DataAccess項目從UI層分割開來。

在你的榜樣的書籍,我的業務層將有一類稱爲書:

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(); 
    } 

} 

這就意味着你的UI完全從實際的數據訪問分離,您的所有圖書的邏輯包含明智地在一個班級內。

您可以使用IoC與Microsoft Unity或Castle等系統進行進一步分離,以便您不必編寫= new LinqToSqlXYZ();,而是可以按照IoC.Resolve<IBookRepostory>();(取決於您的實現)的方式寫東西。這意味着您的Book類不再與LINQ to SQL綁定。

0

Linq to Sql提供實體和數據庫表之間的1:1映射。有人可能會認爲,實體本身是遠離數據庫的抽象級別,這就是你被綁定到的東西。

如果你將linq提供給sql的實體進行1:1的重複,那麼這可能意味着它不值得讓它們在那裏,因爲你仍然與這些類綁定在一起,就像你一樣由linq提供給sql的實體。

通過創建另一個圖層,您還可以將linq提供給sql的更改跟蹤的優勢降低,這意味着您必須將您類中的任何更改複製到由linq提供給sql的實體中以執行數據操作。

如果您想要從任何演示文稿或業務層抽象出DataContext類型代碼,並更緊密地控制數據的接口,那麼存儲庫模式是很好的。您始終可以讓您的存儲庫將由linq創建的實體類型返回給sql,這意味着您不會複製類型,也可以獲取更改跟蹤,但是您仍然保存控制存儲庫內DataContext的代碼。

爲了演示文稿(視圖模型)或業務邏輯的好處,您可能會考慮將數據投影到不同的類中。這是我傾向於下去的路線,如果我想使用linq到sql,但我不想在實體和我的視圖模型之間進行1:1映射。