2009-03-20 49 views
6

Tôi có một số lớp thực thể mà tôi sử dụng để phân tích các tệp văn bản có chiều rộng cố định cũng như sử dụng LINQ to SQL. Tôi sử dụng các lớp này để phân tích dữ liệu từ các tệp văn bản đã nói và so sánh với dữ liệu trong cơ sở dữ liệu.Cách tốt nhất để cập nhật trong LINQ to SQL

Một trong những thực thể này có nhiều thuộc tính và tôi không muốn lãng phí thời gian đặt từng thuộc tính riêng lẻ trên đối tượng kết quả LINQ.

Có cách nào để nói với Linq "Đây là đối tượng của tôi, sử dụng điều này để cập nhật hồ sơ"? Đây là mã tôi đang làm việc trên:

 
if (partialContent.MonthlyAddChange == "A") 
    { 
     bookContentTable.InsertOnSubmit(partialContent); 
    } 
    else if (partialContent.MonthlyAddChange == "C") 
    { 
     var query = from bookContent in bookContentTable 
        where bookContent.EAN == partialContent.EAN 
        select bookContent; 

     if (query != null) 
     { 
      // Do something with query.First() 
     } 
    } 
} 

Tốt hơn bạn nên xóa bản ghi và thực hiện InsertOnSubmit() trong trường hợp này?

+3

Biến "truy vấn" không bao giờ rỗng, chuỗi có thể trống, nhưng không rỗng. –

Trả lời

2

Tôi nghĩ khái niệm chỉnh sửa bản ghi khác với xóa và chèn hình ảnh mới. Về cơ bản, tôi nghĩ rằng một ORM nên trừu tượng đi thế hệ khóa chính và các công cụ liên quan khác. Bằng cách xóa và chèn, bạn có thể loại bỏ tính toàn vẹn của bản ghi (có thể phát hành một khóa chính mới, làm cho các thực thể được tham chiếu không hợp lệ và vv ..). Tôi khuyên bạn nên cập nhật bản ghi bất cứ khi nào hành động bạn đang thực hiện là khái niệm cập nhật.

0

Tôi sẽ không xóa/tạo lại. Giả sử rằng hai đối tượng có cùng một giao diện đối với các thuộc tính mà bạn muốn cập nhật, tôi sẽ sử dụng sự phản chiếu và sao chép các giá trị của sự thay đổi đối tượng hiện có. Nếu bất kỳ giá trị nào khác với giá trị ban đầu, hồ sơ sẽ được đánh dấu là cần được cập nhật và SubmitChanges sẽ xử lý nó.

Ví dụ (với kiểm tra lỗi nhỏ):

foreach (var bookInfo in bookContent.GetType().GetProperties()) 
{ 
    var partialInfo = partialContent.GetType().GetProperty(bookInfo.Name); 
    if (partialInfo != null) 
    { 
     bookInfo.SetValue(partialInfo.GetValue(partialContent, null)); 
    } 
} 

Nếu bạn biết rằng họ là những người cùng loại, bạn có thể tái sử dụng các PropertyInfo đầu tiên thay vì nhận được một cái mới cho partialContent.

1

Tôi nghĩ rằng bạn có thể sử dụng một cái gì đó như DataContext.Table.Attach (ghi lại, đúng) và sau đó DataContext.SubmitChanges(). Nhưng tôi không có nó hoàn toàn thịt ra ...

Vì vậy, bây giờ tôi đã làm một thử nghiệm. Điều này sẽ chỉ hoạt động nếu bạn không yêu cầu kiểm tra đồng thời (tức là bạn là người duy nhất cập nhật bảng).

Dưới đây là bảng tôi

People 
PersonID int 
FirstName varchar(50) 
LastName varchar(50) 

tôi cư bảng với kỷ lục sau

> PersonID  FirstName LastName 
> 1   Jason  Punyon 

Tôi tạo ra một LINQ2SQL DataContext chỉ với bảng này được gọi là PeopleDataContext và trên tất cả các tài sản của lớp người tôi đặt thuộc tính UpdateCheck của mỗi thuộc tính bản ghi thành Không bao giờ.

Dưới đây là các mã:

static void Main(string[] args) 
{ 
    var p = new People(); 
    p.PersonID = 1; 
    p.FirstName = "Jason"; 
    p.LastName = "This is a new last name"; 


    using (var db = new PeopleDataContext()) 
    { 
     db.Peoples.Attach(p, true); 
     db.SubmitChanges(); 
    } 
} 

Và nó hoạt động thành công. Không phản ánh hoặc bất cứ điều gì, nhưng như tôi đã nói, bạn mất kiểm tra đồng thời.

+0

Bạn có thể thay đổi thuộc tính kiểm tra bản cập nhật bằng các chữ cái to hay không, vì đó là câu trả lời cơ bản nếu bạn không cần phải lo lắng về đồng thời –

1

Bạn có thể xóa bản ghi và thực hiện InsertOnSubmit() trong trường hợp này không?

Không, chắc chắn không - chỉ xem xét tính toàn vẹn tham chiếu mà bất kỳ thiết kế DB tốt, ổn định nào nên sử dụng. Nếu hồ sơ của bạn đã được sử dụng bởi các hàng khác, bạn không thể chỉ đơn giản là loại bỏ nó và chèn lại nó - bạn sẽ phá vỡ những ràng buộc toàn vẹn.

Nếu bạn chỉ thay đổi một vài giá trị, hãy cập nhật hàng hiện có - dễ dàng hơn và phù hợp hơn nhiều.

Marc

Các vấn đề liên quan