Tôi có thể sử dụng POCO để làm gì?

Question

Tôi đã đọc một số bài viết về POCO trong khuôn khổ enttity nhưng vẫn không hiểu những gì tôi có thể sử dụng nó. POCO có thể đem lại lợi ích cho dự án của tôi như thế nào?

Answer 1

tiêu chuẩn POCO cho "đối tượng Clr cũ đồng bằng". Nó đề cập đến một phong cách của kiến ​​trúc ORM, nơi tất cả các công việc cho sự bền bỉ và tải dữ liệu từ kho dữ liệu được thực hiện bởi hệ thống với chính đối tượng biết những gì đang xảy ra với nó. Điều này có nghĩa là ORM có thể hỗ trợ hoàn toàn đồng bằng các đối tượng chưa được sửa đổi theo bất kỳ cách nào với ý tưởng ORM. Một ORM hỗ trợ sự kiên trì của các POCO sẽ không yêu cầu bạn phải thừa hưởng lớp của bạn từ bất kỳ cơ sở cụ thể nào, thực hiện bất kỳ giao diện nào hoặc thậm chí các phương thức thẻ với bất kỳ thuộc tính nào.

Hoàn toàn trái ngược với điều này (đôi khi được gọi là Đối tượng truy cập dữ liệu - hoặc DAO) là khi tất cả lưu trữ được xử lý bởi chính đối tượng đó, nó biết chính xác cách sắp xếp và lưu trữ chính nó và cách tải chính nó khi được yêu cầu. Trong trường hợp này, các đối tượng nên được sử dụng hoàn toàn để truyền dữ liệu và không nên đại diện cho bất kỳ logic nghiệp vụ nào của hệ thống.

Trong thực tế, đây là một phổ với hai tình huống ở hai đầu. Nhiều ORM ngồi ở đâu đó ở giữa, đòi hỏi sự kiên trì để được xử lý bên ngoài lớp, nhưng thường đòi hỏi một số siêu dữ liệu hoặc giao diện được triển khai trên các lớp đang được duy trì để giúp mọi thứ cùng.

EF (v1) không hỗ trợ POCO. Các đối tượng phải thực hiện các giao diện khác nhau (để cung cấp thông báo về các giá trị thuộc tính thay đổi, vv) để có thể tồn tại lâu bền bởi khung công tác. Tôi tin rằng có addon frameworks cố gắng thêm hỗ trợ POCO cho EF, nhưng tôi không biết họ thành công như thế nào. EF in .net 4.0 sẽ có hỗ trợ POCO.

POCO thường được coi là tốt vì nó cho phép chia tách mối quan tâm mạnh mẽ. Bạn có thể xác định các đối tượng dữ liệu của bạn để có hoàn toàn không có kiến ​​thức về cơ chế sẽ được sử dụng để lưu trữ chúng. (Vì vậy, nó làm cho nó dễ dàng để chuyển đổi cơ chế lưu trữ cho một cái gì đó khác nhau trong tương lai). Nó cũng có nghĩa là bạn không phải thiết kế các đối tượng dữ liệu của bạn với bất kỳ xem xét nào cho cơ sở dữ liệu/khung được sử dụng để lưu trữ chúng.

Answer 2

POCO chỉ là "đối tượng CLR cũ đồng bằng". Nó chỉ là một lớp tiêu chuẩn, bất kỳ lớp tiêu chuẩn nào.

Xét về EF, mọi người đang đề cập đến việc có thể định cấu hình EF để lưu trữ các lớp của riêng bạn (không được tạo trực tiếp bởi EF) vào cơ sở dữ liệu.

Answer 3

POCO là các lớp được thiết kế để chuyển dữ liệu trong ứng dụng của bạn (ví dụ: di chuyển dữ liệu từ lớp dữ liệu sang lớp ui). Chúng cũng tách cấu trúc ứng dụng của bạn khỏi lược đồ cơ sở dữ liệu của bạn. Trên các dự án nhỏ, đây không phải là vấn đề lớn, nhưng khi dự án phát triển mô hình đối tượng (cách bạn thiết kế các POCO) có xu hướng đi lạc khỏi lược đồ cơ sở dữ liệu.

Các phương pháp khác thường được sử dụng trong .Net là DataTables và DataSets. Thông thường, dữ liệu được lấy ra bằng cách sử dụng tên cột. Cặp vợ chồng này bạn làm tên cột trong cơ sở dữ liệu của bạn. Nếu tên cột thay đổi trong cơ sở dữ liệu bạn ngắt mã.

Answer 4

POCO chỉ là một lớp bình thường, không có thêm giao diện hoặc lớp cơ sở để làm cho nó hoạt động với lớp cơ sở dữ liệu của bạn (trong ngữ cảnh này).

Ưu điểm là: 1) không phụ thuộc vào lớp cơ sở dữ liệu cụ thể đó, vì vậy bạn có thể hoán đổi nó cho một lớp tốt hơn (ví dụ NHibernate) mà không phải sửa đổi bất kỳ điều gì khác ngoài lớp cơ sở dữ liệu.

2) giúp đơn vị kiểm tra các lớp của bạn dễ dàng hơn.

3) không có mã tấm nồi hơi để thông báo khi một tài sản đã thay đổi vv chỉ là đồng bằng getters và setters.

Idealy đối tượng tên miền của bạn được nạp từ ORM, mà không cần đối tượng đó phải có tiếng nói nào trong cách nó được nạp, làm thế nào thay đổi được theo dõi hoặc làm thế nào nó được lưu, vv

NHibernate làm một công việc rất tốt tại đây , yêu cầu duy nhất là bạn phải làm cho tất cả các thuộc tính/phương thức ảo, điều này tốt hơn rất nhiều so với bất kỳ sự phụ thuộc cứng nào.