Thực tiễn tốt nhất để ánh xạ DTO cho đối tượng miền?

Question

Tôi đã nhìn thấy rất nhiều câu hỏi liên quan đến ánh xạ DTO cho đố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 và có ý kiến ​​riêng của mình nhưng tôi đang tìm kiếm thứ gì đó cụ thể hơn một chút.

Tình hình:

Chúng tôi có nhiều đối tượng miền. Chúng tôi đang sử dụng mô hình CSLA để 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 họ. Bạn không muốn vượt qua những 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, nạc để truyền xung quanh trên dây.

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

Phản ứng đầu tiên của tôi là sử dụng Fowler, DTO pattern-type solution. Tôi đã nhìn 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 (một "mapper" hoặc "assembler") được gọi để tạo DTO từ mộ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 lập bản đồ" có xu hướng cực kỳ phức tạp cho 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 gọn gàng. Các 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 viết mà mọi người sử dụng NHibernate xuất hiện để sử dụng phương pháp này.

Có cách nào khác không? Là một trong những cách trên giá trị sử dụng? Nếu có hay không, tại sao?

Cảm ơn mọi thông tin chi tiết trước.

Answer 1

Lợi ích của việc có người lập bản đồ nằm giữa tên miền của bạn và DTO của bạn không xuất hiện khi bạn chỉ hỗ trợ ánh xạ đơn, nhưng khi số lượng ánh xạ tăng lên, mã đó được phân tách khỏi miền sẽ giúp giữ 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 bạn với rất nhiều trọng lượng.

Cá nhân, tôi cố gắng và giữ bản đồ ra khỏ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 người quản lý/dịch vụ". Đây là một lớp nằm giữa ứng dụng và (các) bộ nhớ, và cung cấp logic nghiệp vụ như phối hợp công việc (Nếu bạn sửa đổi A, bạn có thể cũng phải sửa đổi B để dịch vụ A sẽ làm việc với Dịch vụ B).

Nếu có nhiều định dạng kết thúc, tôi có thể xem xét việc tạo trình định dạng có thể cắm được có thể sử dụng mẫu Khách truy cập, ví dụ để chuyển đổi thực thể của tôi, nhưng tôi chưa tìm thấy nhu cầu.

Answer 2

Bạn có thể sử dụng công cụ tự động hóa như the one written by 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ủ.

Answer 3

Bạn cũng có thể thử Otis, một trình ánh xạ đối tượng đến đối tượng. 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

Answer 4

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

Các tính năng:

• hai chiều mapping
• lập bản đồ tự động
• Mapping giữa các loại khác nhau
• lập bản đồ lồng nhau và cầu dẹt
• Lists và Mảng
• Việc xác minh các mối quan hệ
• Kiểm tra các ánh xạ
• Thuộc tính, trường và phương pháp

Answer 5

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

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

Con - loại trừ các thuộc tính nhất định, tập hợp đối tượng miền, v.v., tìm hiểu cú pháp T4.

Answer 6

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

Lập bản đồ 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 thức này soạn bên Assembler của mỗi đầu.

Bạn kết thúc với các 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(); 

Answer 7

Làm thế nào để bạn thấy để thực hiện một constructor trong lớp DTO mà mất như một tham số một đối tượng tên miền?

Say ... Một cái gì đó như thế này

class DTO { 

    // attributes 

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

    // methods 
} 

Answer 8

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 đó: Xin đề nghị. Trong ví dụ trên, DomainObject phụ thuộc vào DTO. Bằng cách này tôi có thể tránh các mã để làm lập bản đồ dto < -> domainobject.

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