Liệu Breeze có cần đến các DTO trong các ứng dụng một trang không?

Question

Tôi đang xây dựng SPA đầu tiên của mình và tôi đã đi xa như xây dựng DTO cho từng thực thể của mình, nhưng tôi thấy dễ dàng và có vẻ như việc xử lý các thay đổi của bạn thành các gói tối thiểu để tối ưu hóa cập nhật/bổ sung/etc.

Lý do tôi xây dựng DTO là "làm phẳng" dữ liệu của mình và giới hạn số lượng dữ liệu tôi đang đặt trên dây, nhưng tôi tự hỏi liệu tôi có cần chi phí này nếu Breeze chăm sóc nó hay không.

Answer 1

Có những lý do cho DTO. "Làm phẳng dữ liệu" là không phải là một trong số đó. Không phải là "hạn chế số lượng dữ liệu tôi đang đặt trên dây".

Breeze hoạt động tốt với đồ thị đối tượng. Hãy tưởng tượng gửi 100 đơn đặt hàng cho khách hàng. Bạn sẽ không muốn lặp lại tên khách hàng trên mỗi đơn đặt hàng DTO. Với Breeze bạn truy vấn cho các đơn đặt hàng của khách hàng (sử dụng một "mở rộng") và bạn nhận được một bản sao của khách hàng và các đơn đặt hàng để đi với nó.

 
var query = new breeze.EntityQuery.from('Customers') 
      .where('Id', 'eq', 42) 
      .expand('orders'); 

Mặt khác, nếu bạn chỉ muốn một danh sách tên khách hàng, sử dụng một "chiếu":

 
var query = new breeze.EntityQuery.from('Customers') // all customers 
      .select('id, companyName'); // project into an anonymous 2-property object 

Sử dụng thỉnh thoảng server-side DTO để xây dựng một cái gì đó mà bạn có thể không dễ dàng tạo ra từ khách hàng (ví dụ, khách hàng-và-tổng-năm-năm-đặt hàng-đô la).

Vấn đề là bạn có thể kết hợp các truy vấn DTO, dự đoán và thực thể để phù hợp với nhu cầu của mình. Bạn không phải đi tất cả một cách này hay cách khác (theo ý kiến ​​của tôi).

Answer 2

Hiện tại chúng tôi đang đánh giá thay đổi từ Knockout thành Angular và Breeze, để loại bỏ nhiều Mã DTO và MTO-Mapping mà chúng tôi đã viết (máy chủ và mã phía máy khách). Những gì chúng tôi đã làm là không phơi bày các DAO nhưng để tạo DTO cho tất cả các thực thể. Điều cuối cùng là, chúng ta đã có trong nhiều trường hợp (không phải tất cả) các lớp trông giống như các đối tượng cơ sở dữ liệu 90%. Điều này dẫn chúng ta đến sự kết hợp rằng DTO trong trường hợp của chúng tôi không có ý nghĩa và chi phí mà chúng tôi đã bỏ ra là nỗ lực lãng phí và chúng tôi cần phải loại bỏ điều này với một cách tiếp cận tốt hơn. Vì vậy, một vòng tái cấu trúc phải bắt đầu :-)

Vì ở đây chúng tôi có hai chuyên gia (@ John và @Ward) ở một nơi, tôi cũng sẽ có cơ hội trả lời câu hỏi và tiếp tục nêu lên mà tôi đã không hoàn toàn trả lời cho bản thân mình cho đến nay và có lẽ John và Ward có thể làm rõ điều này, vì tôi nghĩ rằng đây là khía cạnh quan trọng bên của câu hỏi nếu DTO vẫn còn cần thiết. Nhìn vào gió, có vẻ như nó rất hữu ích để tránh rất nhiều mã DTO và DTO-Mapping và tôi hoàn toàn đồng ý rằng việc sử dụng DTO để nhận được ít hơn dây cùng với gió không có ý nghĩa, bởi vì đó là một cái gì đó được xử lý hoàn hảo bằng cách giải thích ở trên bằng truy vấn ở phía máy khách. Đây là điều tôi hoàn toàn có thể xác nhận và có ý nghĩa. Cũng tạo ra nhiều lớp DTO khác nhau như chúng tôi đã làm không phải là cách tiếp cận tốt nhất. Breeze làm điều này tốt hơn nhiều với mã ít hơn nhiều.

Để sử dụng mã ánh xạ DTO và DTO để phân tách các mối quan tâm tôi vẫn tin là một ý tưởng hay và nguyên tắc, nhưng cũng có rất nhiều chi phí mà có thể trong nhiều trường hợp không cần thiết. Vì vậy, để tận dụng lợi thế của gió, bạn tất nhiên có thể tạo DTO và ghi/tạo siêu dữ liệu ở phía máy khách, nhưng đó không phải là ý tưởng cơ bản về khoe. Bạn có thể sử dụng nó theo cách này, nhưng bạn càng ở lại trên DAOs, bạn càng phải viết ít mã hơn và dự án của bạn càng nhanh. Tuy nhiên, gió vẫn cho phép bạn điều này để các framwork cũng sẽ làm việc với DTOs, nó không chỉ là ý tưởng cơ bản tại sao gió được viết. Một sự pha trộn của cả hai (tiếp xúc với DAO và DTO) có lẽ là cách tiếp cận tốt nhất.

Nhưng khi nào thì sử dụng DTO?

• an
• Complex Logic (tính) hoặc khi bạn không thể sử dụng phương pháp CRUD đơn giản vì quá nhiều phức tạp mà bạn không sẽ không hay không có thể (an ninh) lộ về phía khách hàng.

Trong trường hợp bảo mật, tôi thực sự không chắc chắn 100% và đây là lý do tại sao tôi viết ở đây và muốn hỏi hai chuyên gia. Chúng tôi đang sử dụng EF ở phía máy chủ và những gì có lẽ là ý tưởng tốt nhất là sử dụng các dự đoán về phía máy chủ để bảo mật. Nhưng làm thế nào để làm điều đó ?

Tôi nêu ra câu hỏi này bởi vì tôi nghĩ rằng câu hỏi quan trọng nhất để trả lời là có thể trả lời câu hỏi nếu DTO vẫn cần.

Chúng tôi kết thúc với đoạn mã sau cho EF (trong bản demo đánh giá của chúng tôi):

private IQueryable<News> RestrictFields(IQueryable<News> query) 
    { 
     return query 
      .ToList() // This seemd to be needed, otherwhise I cannot use new News() 
      .Select(t => new News() 
       { 
        Id = t.Id, 
        Text = t.Text, 
        Title = t.Title, 
        Date = t.Date 
       }) 
      .AsQueryable(); 
    } 

Như bạn có thể thấy ở trên, chúng ta có một truy vấn EF. Vì vậy, lần đầu tiên chúng tôi thử chỉ là để chiếu với Tin tức mới(). Điều đó không có tác dụng, vì EF không cho phép bạn sử dụng cùng một lớp DAO trong một phép chiếu, chỉ các đối tượng DTO hoặc các đối tượng ẩn danh. Vì vậy, chúng tôi đã sử dụng giải pháp thay thế ToList() và sau đó là AsQueryable(). Nhưng điều này không có vẻ đúng và hơn nữa có lẽ sau đó các tham số truy vấn từ khách hàng không nhận được vận chuyển đến cơ sở dữ liệu và có lẽ một số sẽ không làm việc vì điều này, như "mở rộng".

Vì vậy, cách tốt nhất để thực hiện phép chiếu ở phía máy chủ vì lý do bảo mật là gì, vì vậy cuối cùng hãy thoát khỏi sự cần thiết của DTO? @ John: Tôi thấy một bài viết của bạn, nơi bạn nói, bạn đã sử dụng chiếu trên Loa trong dự án demo của bạn cho lớp đào tạo của bạn (Angular và Breeze), nhưng tôi không tìm thấy nơi này được thực hiện.

Ở đây tôi thực sự bị mắc kẹt và điều này là dành cho tôi liên kết còn thiếu để biết nếu DTO vẫn còn cần thiết hay không, và làm thế nào nó có thể hoạt động hoàn hảo cùng với Breeze.

Tôi hy vọng câu trả lời của tôi sẽ giúp trả lời một chút câu hỏi của bạn và hơn nữa tôi hy vọng nó cũng cung cấp cho bạn Jake một số liên kết rất quan trọng trong việc sử dụng khoe và nếu DTO vẫn còn cần thiết.

Trân trọng!

Chris