2009-07-13 45 views
7

Sử dụng VS 2008 & NET 3.5 SP1:WCF, Entity Framework & Dữ liệu Hợp đồng

Tôi đang sử dụng WCF cho phép khách hàng để kết nối với một dịch vụ mà đọc và viết mục cơ sở dữ liệu sử dụng Entity Framework. Theo mặc định các thực thể được tạo tự động từ cơ sở dữ liệu có thuộc tính DataContract được áp dụng.

Rất tiếc, nhiều trường bị lộ không có nghĩa là khách hàng tiêu thụ (tức là - hồ sơ của người đang truy cập dữ liệu nào, v.v.) và vì lý do bảo mật, tôi muốn giữ chúng tiếp xúc. Có cách nào để tránh các lớp khung Entity không bị lộ theo cách này không?

Lưu ý: Đây không phải là bản sao của How to prevent private properties in .NET entities from being exposed as public via services?. Trong câu hỏi đó, người dùng muốn hiển thị có chọn lọc các trường nhất định, trong khi tôi muốn thực thể không được hiển thị dưới dạng một DataContract.

Xin cảm ơn trước.

+0

Điều này có thể tương tự như một bài đăng khác chưa được trả lời hoàn toàn: 'wcf và khung thực thể ADO', http://stackoverflow.com/questions/828302/wcf-and-ado-entity-framework – Malcolm

+0

Tôi đồng ý với câu trả lời trên liên kết "wcf và ADO entity framework" mà bạn đã cung cấp. Hoặc bạn có thể triển khai một số kiểu kho lưu trữ. – NikolaiDante

+1

@Nath - Tôi chắc chắn đồng ý với câu trả lời về "khung công tác của tổ chức wcf và ADO", nhưng tiếc là nó không giải quyết được sự cố của tôi. Điểm đầu tiên trong câu trả lời là "Tự động tạo các thực thể khung thực thể", sẽ hiển thị dữ liệu mà tôi muốn giữ riêng tư dưới dạng DataContracts. Một mẫu kho lưu trữ sẽ có cùng một vấn đề nếu nó được hỗ trợ bởi một mô hình EF cũng được tạo ra theo cách này - trừ khi tôi thiếu một cái gì đó? – Malcolm

Trả lời

13

Bạn có biết rằng thực thể của bạn không cần để ánh xạ 1-1 với cơ sở dữ liệu? Cụ thể, bạn có thể bỏ qua các cột hoặc thậm chí toàn bộ các bảng không có liên quan.

Mô hình thực thể có nghĩa là một mô hình khái niệm. Bạn có thể dễ dàng tạo một tập hợp các thực thể để tiếp xúc với một tập hợp các máy khách (dịch vụ web, có lẽ), và một bộ khác, ánh xạ tới cùng một cơ sở dữ liệu, có nghĩa là cho một ứng dụng khách (ứng dụng web khác nhau).

Mặt khác, tôi luôn khuyên bạn nên chống lại các đối tượng Khuôn khổ thực thể phơi bày thông qua dịch vụ web. Microsoft không may cho thấy các thuộc tính phụ thuộc vào việc triển khai thực hiện bằng cách đánh dấu chúng với [DataMember]. Bây giờ tôi đã thử điều này với một dịch vụ đơn giản trả về một SalesOrderHeader từ AdventureWorks.khách hàng nhận được của tôi phiên bản proxy của các loại EF sau:

  • EntityKeyMember
  • StructuralObject
  • EntityObject
  • EntityKey
  • EntityReference
  • RelatedEnd

Đây không phải là điều khách hàng của bạn cần biết.

Tôi thích hiển thị đối tượng chuyển dữ liệu và sao chép các thuộc tính từ cái này sang cái kia. Rõ ràng, điều này được thực hiện tốt hơn thông qua sự phản chiếu hoặc tạo mã, hơn là bằng tay. Tôi đã thực hiện nó thông qua việc tạo mã trong quá khứ (mẫu T4).

Tùy chọn tôi chưa thử là AutoMapper.

+0

Cảm ơn bạn đã trả lời, John. Vâng, tôi biết rằng các thực thể không cần phải lập bản đồ một-một và có thể mô hình hóa một tập hợp con của mô hình khái niệm, nhưng tôi không nghĩ điều đó sẽ cho tôi kết quả mà tôi hy vọng. Dưới đây là ví dụ: Giả sử tôi có một bảng tài khoản trong hệ thống kế toán và tôi muốn kiểm tra những hoạt động nào đang được thực hiện trên tài khoản nào. Tôi cần để lộ các trường từ bảng tài khoản, nhưng tôi không muốn kẻ gian lận tiềm năng của tôi xem thông tin nào tôi đang theo dõi về hành động của anh ta. Tiếp tục trong bình luận tiếp theo ... – Malcolm

+0

... Tiếp tục từ bình luận trước. Khi khách hàng gọi một hàm tôi muốn tạo một bản ghi và chèn nó vào bảng kiểm tra của tôi để theo dõi và phân tích. Tôi muốn có cả hai accesible qua EF (cho dù họ đang ở trong cùng một container hoặc thực thể riêng biệt không phải là quan trọng với tôi). Thật không may bất cứ điều gì tôi xác định là một phần của mô hình dữ liệu được tiếp xúc như một DataContract. – Malcolm

+0

Vì vậy, đừng vạch trần mô hình dữ liệu đó. Hiển thị mô hình dữ liệu nhỏ hơn - mô hình bạn muốn tiếp xúc. Không phơi bày mô hình tương tự với kẻ gian lận tiềm năng khi bạn thực hiện với hệ thống kiểm toán. –

3

Chúng tôi sử dụng các lớp riêng biệt cho các đối tượng DataContract. Chúng ta có một giao diện với một phương thức, ToContract() và tất cả các thực thể của chúng ta thực hiện giao diện này trong một tệp lớp một phần. Đó là công việc phụ, và đó là bản mẫu, nhưng có vẻ như cách đơn giản nhất để có được sự tách biệt và độ chi tiết của kiểm soát mà chúng ta cần.

2

tôi về cơ bản thấy hai điều bạn có thể làm:

  1. Hoặc bạn loại bỏ những mục bạn không muốn để lộ từ DataContract bằng tay loại bỏ các [DataMember] thuộc tính trên những mặt hàng; Trong trường hợp đó, WCF sẽ không tuần tự hóa các thuộc tính ra
  2. Bạn định nghĩa các lớp WCF DataContract của riêng mình chỉ với những thành viên bạn muốn, và bạn đưa ra một logic để chuyển đổi từ các thực thể EF sang WCF DataContract của bạn. một cái gì đó như AutoMapper để loại bỏ (hoặc ít nhất là giới hạn) các hoạt động xác nhận tẻ nhạt giữa các thực thể EF và WCF.

Marc

+0

Cảm ơn, marc_s. Đối với điểm 1 ở trên, làm cách nào để tôi xóa thuộc tính [DataMember] theo cách thủ công khỏi các mục được tạo tự động từ cơ sở dữ liệu? Điều này sẽ yêu cầu rework thủ công mỗi khi tôi cập nhật mô hình từ cơ sở dữ liệu? – Malcolm

+0

Thật không may, có, tôi sợ không có cách tự động nào để ngăn chặn những thuộc tính [DataMember] mà tôi muốn biết. Do đó ý tưởng về các lớp WCF riêng biệt mà bạn kiểm soát đầy đủ. –

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