C# Lớp dữ liệu và Dto's

Question

Gần đây tôi đã tham gia một công ty sử dụng bộ dữ liệu đã nhập làm 'Dto' của họ. Tôi nghĩ rằng họ thực sự là rác rưởi và muốn thay đổi nó thành một thứ gì đó hiện đại hơn và thân thiện với người dùng hơn. Vì vậy, tôi đang cố gắng cập nhật mã để lớp dữ liệu chung chung hơn, tức là sử dụng giao diện v.v., người kia không biết Dto là gì và chúng tôi có một chút bất đồng về việc nên làm như thế nào.

Không cố gắng gây ảnh hưởng đến mọi người theo cách suy nghĩ của mình, tôi muốn nhận được câu trả lời vô tư từ bạn về những lớp mà Dto có thể hiện diện. Tất cả các lớp; DAL, BL và Bản trình bày hoặc một bộ phụ nhỏ trong các lớp này chỉ.

Ngoài ra, liệu các đối tượng IList có nên hoặc không nên có mặt trong DAL hay không.

Cảm ơn.

Answer 1

Nó thực sự phụ thuộc vào kiến ​​trúc của bạn.

Đối với hầu hết các điểm, bạn nên cố gắng mã để giao diện sau đó nó không thực sự quan trọng những gì bạn thực hiện được. Nếu bạn trả về ISomething nó có thể là SomethingEntity của bạn hoặc SomethingDTO của bạn nhưng mã tiêu thụ của bạn không quan tâm ít miễn là nó thực hiện giao diện.

Bạn phải trả lại IList/ICollection/IEnumerable trên một tập hợp hoặc mảng cụ thể.

• Properties should not return arrays
• Do not expose generic lists

gì bạn nên cố gắng làm đầu tiên là tách biệt mã của bạn và làm cho nó lỏng lẻo bằng cách chèn một số giao diện giữa các lớp của bạn như một kho lưu trữ cho lớp DataAccess của bạn. Kho lưu trữ của bạn sau đó trả về các thực thể của bạn được đóng gói bởi một giao diện. Điều này sẽ làm cho mã của bạn dễ kiểm tra hơn và cho phép bạn giả lập dễ dàng hơn. Một khi bạn đã thử nghiệm tại chỗ, bạn có thể bắt đầu thay đổi việc triển khai với ít rủi ro hơn.

Nếu bạn bắt đầu sử dụng giao diện, tôi khuyên bạn nên tích hợp một IoC như Windsor sớm hơn là sau này. Nếu bạn làm điều đó từ khi đi, nó sẽ làm cho mọi thứ dễ dàng hơn sau này.

Answer 2

Một điều là DataSets kém để đạt được khả năng tương tác. Ngay cả các tập dữ liệu đã nhập cũng không tương thích khi nói đến việc tiêu thụ các tập dữ liệu đã nhập từ một máy khách không phải là .net. Tham khảo this link. Nếu bạn phải đạt được khả năng tương tác thì hãy chiến đấu khó khăn cho DTO nếu không cố gắng làm cho nhóm của bạn hiểu DTO trong một khoảng thời gian vì các tập dữ liệu không quá tệ sau tất cả.

Trên một phần của giao diện, có bạn nên phơi bày giao diện. Ví dụ: - Nếu bạn đang trả lại List<T> từ DAL, thay vào đó bạn phải trả lại IList<T>. Một số người đi đến mức độ chỉ trả lại IEnumerable<T> bởi vì tất cả những gì bạn cần là khả năng liệt kê. Nhưng sau đó trong khi thực hiện nó không trở thành astronaut architect.

Trong các ứng dụng của tôi, tôi đã tìm ra rằng trở IList<T> thay vì gây ô nhiễm List<T> cơ sở mã của tôi với các mã như thế này:

//consider personCollection as IList<Person> 
(personCollection as List<Person>).ForEach(//Do Something) 

Vì vậy, cá nhân tôi cố gắng duy trì một sự cân bằng giữa trở về giao diện hoặc đối tượng cụ thể. Nếu bạn hỏi tôi những gì tôi đang làm ngay bây giờ, sau đó tôi sẽ cho bạn biết tôi đang trở về List<T>. Tôi bị ảnh hưởng không trở thành astronaut architect.

Answer 3

Tôi luôn sử dụng DTO, không bao giờ DataTable. Nhưng tôi chỉ sử dụng chúng để chuyển từ BL sang DL và ngược lại. Các lớp trình bày của tôi thường chỉ nhận thức được các lớp kinh doanh và dịch vụ trong trường hợp định hướng dịch vụ.

Những lợi ích tôi có thể thấy sử dụng DTOs hơn datatables:

• dễ refactoring
• sản xuất dễ dàng sơ đồ
• mã sạch dễ đọc hơn, đặc biệt là trong đơn vị của Dal kiểm tra

Answer 4

Theo định nghĩa, DTO là một đối tượng truyền dữ liệu, được sử dụng để (đợi) chuyển dữ liệu từ lớp này sang lớp khác.

DTO có thể được sử dụng trên tất cả các lớp và tôi đã sử dụng chúng tốt với các dịch vụ web.