2011-01-14 15 views
5

Tôi đang cố gắng viết một ứng dụng nhỏ có ranh giới rất nghiêm ngặt giữa BLL và DAL và bây giờ tự hỏi cách tốt nhất để truyền dữ liệu (Domain Transfer Objects) giữa các lớp.Làm thế nào để sử dụng DTO giữa UI, BLL, DAL

Tôi đã triển khai một số lớp trong Cấp miền (thư viện lớp) được truy cập bởi cả BLL và DAL. Các lớp này về cơ bản chỉ chứa các thành phần thuộc tính/dữ liệu và hiện đang phản ánh dữ liệu DAL. Ví dụ:

class CustomerData 
{ 
    // some data fields 
} 

Sau đó, tôi thực hiện một số lớp học trong BLL như:

class Customer : CustomerData 
{ 
    // Some methods 
} 

Trong Dal của tôi tôi nhận được hồ sơ khách hàng từ cơ sở dữ liệu thông qua LINQ-to-SQL. sau đó tôi lập bản đồ các đối tượng LINQ to đối tượng tên miền của tôi bằng cách:

CustomerData.field = LinqObject.field 
// Etc 

suy nghĩ của tôi là như vậy, mà tôi bây giờ là một ví dụ CustomerData từ Dal của tôi để BLL khi được yêu cầu (và rằng tôi nên vượt qua một trường hợp khách hàng đến giao diện người dùng của tôi).

Trong BLL của tôi, do đó tôi sẽ nhận được một cá thể CustomerData, nhưng bây giờ tôi muốn làm cho một Khách hàng ra khỏi nó.

Câu hỏi:

  1. Tôi có phải trong BLL của tôi bây giờ tạo một đối tượng khách hàng và LẠI sao chép tất cả các thành viên lĩnh vực?
    Khách hàng c = Khách hàng mới; c.field = CustomerData.field;
  2. Làm cách nào để tạo Khách hàng từ CustomerData mà không có các bước sao chép trường?
  3. Tôi có nên thay vì sử dụng bố cục không?
    lớp Khách hàng { Dữ liệu khách hàngData; }
  4. Có cách nào hiệu quả hơn (ít mã hóa hơn) để thực hiện việc này trong bố cục hiện tại của tôi không?
  5. Có cách nào tốt hơn để thực hiện việc này không?
  6. Mọi nhận xét nói chung?

Cảm ơn!

+0

Câu trả lời của Yorah +8 cho số 1. Khỉ mã hóa như vậy có thể chỉ có vẻ giống như một nỗi đau cho bạn. Cuối cùng nó thực sự là điều sai trái để làm bởi vì mức độ mà nó làm tăng lỗi và làm cho những điều như một nỗi đau trong một $$. Hãy thử ValuInjector - nhiều người thích nó tốt hơn AutoMapper, nhẹ hơn nhiều. Bên cạnh việc tái sử dụng ánh xạ của bạn. – FastAl

Trả lời

8

nói chung tôi xem DTO không phải là lớp cụ thể, được tạo/tiêu thụ bởi DAL, được xử lý bởi BLL và được tiêu thụ/tạo bởi giao diện người dùng.

thường mỗi lớp là một dự án riêng biệt trong thư mục giải pháp VS, do đó, DTO là một dự án khác được tham chiếu bởi mỗi lớp.

theo cách này nếu có trường cần tồn tại trong giao diện người dùng nhưng không tồn tại trong các lớp khác, DTO có thể được kế thừa từ đó.

0

bạn không hoàn toàn sử dụng DTO. Trong lớp Customer của bạn, hãy trả lại CustomerData trực tiếp vào giao diện người dùng của bạn.

và không có cần phải kế thừa Customer từ CustomerData

EDIT: tôi sử dụng từ đầy đủ ở đây vì CustomerData là DTO, vì vậy thay vì trả lại khách hàng, trở CustomerData vì nó là DTO như thể hiện trong những điều sau đây sơ đồ.

Một đề xuất, bạn nên sử dụng Repository Pattern để tách BLL và DAL của bạn.

DTO 1]

+0

Làm cách nào để "sử dụng đầy đủ" DTO? – Oliver

+0

@Oliver đã cập nhật câu trả lời. – Adeel

+2

Một số cho tôi một bài viết có ví dụ minh hoạ rõ ràng về DTO và sự tương tác giữa BLL và DAL Đó không phải là mô hình Anti-Pattern mẫu chống dịch . Điều đó gây nhầm lẫn cho tôi – Costa

2

Một số lưu ý từ quan điểm của tôi đến đây, tôi không phải là một lời sấm nhưng hy vọng nó sẽ đưa ra một số sự giúp đỡ :)

Đối với tôi nó cảm thấy rằng bạn có quá nhiều " mô hình "ở đây. Nó có thể gây nhầm lẫn và dẫn đến rất nhiều mã chỉ để sao chép dữ liệu giữa các biểu diễn khác nhau. Và rất nhiều mã có nghĩa là nhiều lỗi hơn. Sau đó, tôi nghĩ rằng sự kế thừa giữa các lớp dữ liệu của bạn và các loại lớp nghiệp vụ của giới hạn bạn khi xác định các lớp kinh doanh của bạn. Làm thế nào về nếu bạn muốn tạo ra một lớp kinh doanh được sáng tác bởi một số lớp dữ liệu? Bạn nên sử dụng giao diện hoặc thành phần tôi nghĩ.

Thông thường, tôi chỉ làm việc với một mô hình khái niệm phản ánh tên miền doanh nghiệp. Mô hình này được sử dụng cả bởi dữ liệu và lớp kinh doanh và trong một số trường hợp thậm chí là lớp trình bày (trong các ứng dụng nhỏ hơn), như Dead Rabit chỉ ra. Để duy trì độ bền, tôi sử dụng O/RM như EF 4.

Đối với các dự án lớn hơn, đặc biệt trong các trường hợp phân tán, tôi sử dụng tùy chỉnh DTO cho (các) lớp giao diện người dùng. Các lớp này phản ánh nhu cầu của giao diện người dùng và có thể khác nhiều so với các thực thể trong mô hình khái niệm.

Cá nhân, tôi nghĩ Entity Framework 4 giúp bạn rất nhiều khi xây dựng ứng dụng theo cấu trúc này, nếu bạn đang ở giai đoạn đầu của dự án và sử dụng .NET 4 bạn có thể muốn kiểm tra nó?

  1. Có, bạn có thể cần.
  2. Sử dụng phần
  3. Vâng, tôi sẽ sử dụng phần
  4. Sử dụng ví dụ Entity Framework 4
  5. (- "-)
  6. xem ở trên
+0

Chắc chắn sẽ kiểm tra EF4. Bản án ban đầu của tôi cũng có quá nhiều lớp cho ứng dụng này. Nhưng trong quá khứ các lớp của tôi luôn luôn "bị rò rỉ" quá nhiều, vì vậy tôi đang cố gắng để được nghiêm khắc về bản thân mình ở đây. – Oliver

1

Nếu bạn nhấn mạnh vào việc có một vài lớp trên DTO, bạn có thể sử dụng AutoMapper để giúp bạn chuyển đổi từ người này sang người khác trong một dòng mã (bằng cách sử dụng cùng một quy ước trong DTO của bạn)

CustomerData customerData = Mapper.Map<LinqObject, CustomerData>(linqObjectInstance); 

Bạn cũng nên xem xét các mô hình PresentationModel: http://martinfowler.com/eaaDev/PresentationModel.html

Bạn cũng có thể google cho MVVM (Model-View-ViewModel) nếu bạn muốn đi theo con đường này.

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