如果讓數據訪問遠離業務層和表示層非常重要,那麼我可以採取哪些替代方法或方法,以便我的LINQ to SQL實體可以保留在數據訪問層?從LINQ到SQL實體的UI代碼中分離數據
到目前爲止,我似乎只是簡單地複製sqlmetal生成的類,並傳遞這些對象,而不是簡單地保留兩個appart。
例如,我在我的數據庫中有一張名爲Books的表格。如果用戶通過UI創建新書,由sqlmetal生成的Book類看起來像是一個完美的適合,儘管我通過這樣做來緊密耦合我的設計。
如果讓數據訪問遠離業務層和表示層非常重要,那麼我可以採取哪些替代方法或方法,以便我的LINQ to SQL實體可以保留在數據訪問層?從LINQ到SQL實體的UI代碼中分離數據
到目前爲止,我似乎只是簡單地複製sqlmetal生成的類,並傳遞這些對象,而不是簡單地保留兩個appart。
例如,我在我的數據庫中有一張名爲Books的表格。如果用戶通過UI創建新書,由sqlmetal生成的Book類看起來像是一個完美的適合,儘管我通過這樣做來緊密耦合我的設計。
我所做的是在一個項目中使用我的所有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綁定。
Linq to Sql提供實體和數據庫表之間的1:1映射。有人可能會認爲,實體本身是遠離數據庫的抽象級別,這就是你被綁定到的東西。
如果你將linq提供給sql的實體進行1:1的重複,那麼這可能意味着它不值得讓它們在那裏,因爲你仍然與這些類綁定在一起,就像你一樣由linq提供給sql的實體。
通過創建另一個圖層,您還可以將linq提供給sql的更改跟蹤的優勢降低,這意味着您必須將您類中的任何更改複製到由linq提供給sql的實體中以執行數據操作。
如果您想要從任何演示文稿或業務層抽象出DataContext
類型代碼,並更緊密地控制數據的接口,那麼存儲庫模式是很好的。您始終可以讓您的存儲庫將由linq創建的實體類型返回給sql,這意味着您不會複製類型,也可以獲取更改跟蹤,但是您仍然保存控制存儲庫內DataContext
的代碼。
爲了演示文稿(視圖模型)或業務邏輯的好處,您可能會考慮將數據投影到不同的類中。這是我傾向於下去的路線,如果我想使用linq到sql,但我不想在實體和我的視圖模型之間進行1:1映射。