Các phương pháp hay nhất để ánh xạ DTO với đối tượng miền?

Tôi đã thấy rất nhiều câu hỏi liên quan đến ánh xạ DTO với các đối tượng miền, nhưng tôi không cảm thấy họ trả lời câu hỏi của tôi. Tôi đã sử dụng nhiều phương pháp trước đây và có ý kiến ​​của riêng mình nhưng tôi đang tìm kiếm thứ gì đó cụ thể hơn một chút.

Tình huống:

Chúng tôi có nhiều đối tượng miền. Chúng tôi đang sử dụng mô hình CSLA nên các đối tượng miền của chúng tôi có thể khá phức tạp và chúng chứa quyền truy cập dữ liệu của riêng chúng. Bạn không muốn chuyển những thứ này xung quanh trên dây. Chúng tôi sẽ viết một số dịch vụ mới sẽ trả về dữ liệu ở một số định dạng (.Net, JSON, v.v.). Vì lý do này (và các lý do khác), chúng tôi cũng đang tạo một đối tượng truyền dữ liệu tinh gọn để truyền trên dây.

Câu hỏi của tôi là: Đối tượng DTO và Domain nên được kết nối như thế nào?

Phản ứng đầu tiên của tôi là sử dụng dung dịch kiểu mẫu DTO Fowler . Tôi đã thấy điều này được thực hiện nhiều lần và nó cảm thấy phù hợp với tôi. Đối tượng miền không chứa tham chiếu đến DTO. Một thực thể bên ngoài ("người lập bản đồ" hoặc "trình hợp dịch") được gọi để tạo DTO từ Đối tượng miền. Thông thường có một ORM ở phía đối tượng miền. Nhược điểm của điều này là "người vẽ bản đồ" có xu hướng trở nên cực kỳ phức tạp đối với bất kỳ tình huống thực tế nào và có thể rất mong manh.

Một ý tưởng khác được đưa ra là để Đối tượng miền "chứa" DTO, vì nó chỉ là một đối tượng dữ liệu đơn giản. Thuộc tính Đối tượng miền sẽ tham chiếu nội bộ các thuộc tính DTO và chỉ có thể trả về DTO nếu được yêu cầu. Tôi có thể thấy không có vấn đề với điều này nhưng nó cảm thấy sai. Tôi đã thấy một số bài báo mà những người sử dụng NHibernate dường như sử dụng phương pháp này.

Có những cách khác? Một trong những cách trên có đáng sử dụng không? Nếu có hoặc nếu không, tại sao?

Lợi ích của việc có một trình ánh xạ nằm giữa miền của bạn và DTO của bạn không xuất hiện khi bạn chỉ hỗ trợ một ánh xạ duy nhất, nhưng khi số lượng ánh xạ tăng lên, việc tách mã đó khỏi miền sẽ giúp giữ cho miền đơn giản và gọn gàng hơn. Bạn sẽ không làm lộn xộn miền của mình với quá nhiều trọng lượng.

Cá nhân tôi cố gắng giữ ánh xạ ngoài các thực thể miền của mình và đặt trách nhiệm vào cái mà tôi gọi là "Lớp quản lý / Dịch vụ". Đây là lớp nằm giữa ứng dụng và (các) kho lưu trữ và cung cấp logic nghiệp vụ như điều phối quy trình làm việc (Nếu bạn sửa đổi A, bạn cũng có thể phải sửa đổi B để dịch vụ A sẽ hoạt động với Dịch vụ B).

Nếu tôi có nhiều định dạng kết thúc có thể xảy ra, tôi có thể xem xét việc tạo một trình định dạng có thể cắm thêm có thể sử dụng mẫu Khách truy cập, chẳng hạn như để chuyển đổi các thực thể của tôi, nhưng tôi chưa thấy cần thiết cho bất kỳ thứ gì phức tạp này.

Bạn có thể sử dụng một trình tự động hóa, chẳng hạn như một trình tự động được viết bởi Jimmy Bogard không có kết nối giữa các đối tượng và dựa vào các quy ước đặt tên được tuân thủ.

Chúng tôi sử dụng các mẫu T4 để tạo các lớp ánh xạ.

Pro's - mã có thể đọc được của con người có sẵn tại thời điểm biên dịch, nhanh hơn trình lập bản đồ thời gian chạy. Kiểm soát 100% mã (có thể sử dụng một phần các phương pháp / mẫu mẫu để mở rộng chức năng trên cơ sở đặc biệt)

Con's - loại trừ một số thuộc tính, tập hợp các đối tượng miền, v.v., học cú pháp T4.

Giữ logic ánh xạ bên trong thực thể của bạn có nghĩa là Đối tượng miền của bạn giờ đây đã biết về "chi tiết triển khai" mà nó không cần biết. Nói chung, DTO là cửa ngõ của bạn với thế giới bên ngoài (từ một yêu cầu đến hoặc thông qua việc đọc từ một dịch vụ / cơ sở dữ liệu bên ngoài). Vì thực thể là một phần của Logic kinh doanh của bạn, có lẽ tốt nhất bạn nên giữ những chi tiết đó bên ngoài thực thể.

Giữ bản đồ ở một nơi khác sẽ là giải pháp thay thế duy nhất - nhưng nó nên đi đâu? Tôi đã thử giới thiệu các đối tượng / dịch vụ ánh xạ nhưng, sau khi tất cả đã được nói và thực hiện, có vẻ như khai thác quá mức (và có thể là như vậy). Tôi đã có một số thành công khi sử dụng Automapper và những thứ như vậy cho các dự án nhỏ hơn nhưng các công cụ như Automapper đi kèm với những cạm bẫy của riêng chúng. Tôi đã gặp một số vấn đề khá khó khăn để tìm ra các vấn đề liên quan đến ánh xạ vì ánh xạ của Automapper là ẩn và hoàn toàn tách rời khỏi phần còn lại của mã của bạn (không giống như "tách các mối quan tâm" mà giống như "ánh xạ của Godforsaken sống ở đâu") vì vậy chúng đôi khi có thể khó theo dõi. Không có nghĩa là Automapper không có công dụng của nó, bởi vì nó có. Tôi chỉ nghĩ rằng việc lập bản đồ phải là thứ rõ ràng và minh bạch nhất có thể để tránh các vấn đề.

Thay vì tạo một lớp dịch vụ ánh xạ, tôi đã thành công trong việc giữ các ánh xạ bên trong DTO của mình. Vì DTO luôn nằm ở ranh giới của ứng dụng, chúng có thể được biết đến về Đối tượng kinh doanh và tìm ra cách ánh xạ từ / đến chúng. Ngay cả khi số lượng ánh xạ mở rộng đến một lượng hợp lý, nó vẫn hoạt động rõ ràng. Tất cả các ánh xạ ở cùng một nơi và bạn không phải quản lý một loạt các dịch vụ ánh xạ bên trong Lớp dữ liệu, Lớp chống gián đoạn hoặc Lớp trình bày của mình. Thay vào đó, ánh xạ chỉ là một chi tiết triển khai được ủy quyền cho DTO liên quan đến yêu cầu / phản hồi. Vì các bộ tuần tự hóa thường chỉ tuần tự hóa các thuộc tính và trường khi bạn gửi nó qua đường dây, bạn sẽ không gặp phải bất kỳ vấn đề nào. Cá nhân tôi thấy đây là lựa chọn sạch sẽ nhất và tôi có thể nói, theo kinh nghiệm của mình,

Bạn thấy như thế nào để triển khai một phương thức khởi tạo bên trong lớp DTO nhận làm tham số cho một đối tượng miền?

Nói ... Chuyện như thế này

class DTO {

     // attributes 

     public DTO (DomainObject domainObject) {
          this.prop = domainObject.getProp();
     }

     // methods
}

Một giải pháp khả thi khác: http://glue.codeplex.com .

Đặc trưng:

• Ánh xạ hai chiều
• Ánh xạ tự động
• Ánh xạ giữa các loại khác nhau
• Lập bản đồ lồng nhau và Làm phẳng
• Danh sách và Mảng
• Xác minh các mối quan hệ
• Kiểm tra ánh xạ
• Thuộc tính, trường và phương thức

Bạn cũng có thể thử Otis, một trình ánh xạ Object-to-object. Các khái niệm tương tự như ánh xạ NHibernate (thuộc tính hoặc XML).

http://code.google.com/p/otis-lib/wiki/GettingStarted

Tôi có thể đề xuất một công cụ tôi đã tạo và là mã nguồn mở được lưu trữ tại CodePlex: EntitiesToDTOs .

Ánh xạ từ DTO đến Thực thể và ngược lại được thực hiện bằng các phương pháp mở rộng, các phương pháp này tạo thành bên Bộ lắp ráp của mỗi đầu.

Bạn kết thúc bằng mã như:

Foo entity = new Foo();
FooDTO dto = entity.ToDTO();
entity = dto.ToEntity();

List<Foo> entityList = new List<Foo>();
List<FooDTO> dtoList = entityList.ToDTOs();
entityList = dtoList.ToEntities();

Tại sao chúng ta không thể làm như thế này?

class UserDTO {
}

class AdminDTO {
}

class DomainObject {

 // attributes
 public DomainObject(DTO dto) {
      this.dto = dto;
 }     

 // methods
 public function isActive() {
      return (this.dto.getStatus() == 'ACTIVE')
 }

 public function isModeratorAdmin() {
      return (this.dto.getAdminRole() == 'moderator')
 }

}


userdto = new UserDTO();
userdto.setStatus('ACTIVE');

obj = new DomainObject(userdto)
if(obj.isActive()) {
   //print active
}

admindto = new AdminDTO();
admindto.setAdminRole('moderator');

obj = new DomainObject(admindto)
if(obj.isModeratorAdmin()) {
   //print some thing
}

@FrederikPrijck (hoặc) ai đó: Vui lòng đề xuất. Trong ví dụ trên, DomainObject phụ thuộc vào DTO. Bằng cách này, tôi có thể tránh mã để ánh xạ đối tượng dto <--> domainobject.

hoặc lớp DomainObject có thể mở rộng lớp DTO?

Một tùy chọn khác sẽ là sử dụng ModelProjector . Nó hỗ trợ tất cả các tình huống có thể xảy ra và rất dễ sử dụng với diện tích tối thiểu.

Chúng ta có thể sử dụng mẫu Factory, Memento và Builder cho việc đó. Nhà máy ẩn các chi tiết về cách tạo phiên bản của mô hình miền từ DTO. Memento sẽ đảm nhận việc tuần tự hóa / giải mã hóa mô hình miền đến / từ DTO và thậm chí có thể truy cập các thành viên riêng tư. Builder sẽ cho phép ánh xạ từ DTO sang miền với giao diện thông thạo.