2

Tôi hiện đang sử dụng một tập hợp các đối tượng cốt lõi rất đơn giản trong lớp mô hình của mình: các thực thể, các trình ánh xạ và các đối tượng dịch vụ.

Các thực thể là các đối tượng đại diện cho một cái gì đó trong logic kinh doanh của tôi. Ví dụ, trong hướng dẫn Album truyền thống của tôi, thực thể sẽ là đối tượng chứa một album. Nó có các thuộc tính như tiêu đề, nghệ sĩ và ngày được tạo và các phương thức dành riêng cho thực thể này.

Mappers biết cách lưu và tải một thực thể từ kho lưu trữ dữ liệu. Đây có thể là cơ sở dữ liệu hoặc dịch vụ web hoặc tệp CSV trên đĩa. Không có yêu cầu rằng một thực thể nhất định ánh xạ tới một bảng cơ sở dữ liệu (hoặc tệp trên đĩa) vì trình ánh xạ có thể chỉ cần sử dụng nhiều bảng cho các thuộc tính khác nhau trong thực thể nếu nó muốn. Thực thể không có kiến ​​thức về cách nó được tải và lưu. Sự cô lập này có nghĩa là tôi có thể có nhiều người lập bản đồ cho cùng một thực thể lưu trữ nó vào các kho dữ liệu khác nhau.

Các đối tượng dịch vụ cung cấp API mà phần còn lại của ứng dụng sử dụng. Tôi cho phép các bộ điều khiển và xem người trợ giúp nói chuyện với các đối tượng dịch vụ, mặc dù tôi đánh giá cao rằng những người khác có một cách khác về MVC. Bất kỳ đối tượng dịch vụ cụ thể nào cũng biết về trình ánh xạ và thực thể và bất kỳ điều gì khác mà logic nghiệp vụ yêu cầu. Tôi thích có một đối tượng dịch vụ vì tôi có thể làm lại những người lập bản đồ làm gì mà không cần phải chạm vào phần còn lại của ứng dụng. Lớp dịch vụ cũng biết về các chi tiết ứng dụng khác như gửi email sau khi gửi biểu mẫu. Trong một hệ thống dựa trên sự kiện, chẳng hạn như ZF2, các chi tiết này giờ đây có thể sống trong các đối tượng của riêng chúng, chúng lắng nghe các sự kiện được kích hoạt bởi đối tượng dịch vụ.

Tôi không thích cụm từ "đối tượng dịch vụ" vì từ "dịch vụ" có nghĩa là rất nhiều điều với rất nhiều người. Tôi chưa nghe thấy một cụm từ tốt hơn mà mọi người đều hiểu.



|