Nơi để xây dựng các thực thể tên miền mới? Bộ điều khiển, kho lưu trữ hoặc trình ánh xạ?

Question

Giả sử đối với mỗi thực thể tên miền, tôi có một kho lưu trữ cung cấp API cho trình ánh xạ dữ liệu. Ví dụ, nếu tôi có một UserEntity, thì tôi sẽ có một UserRepository mà nói với một UserMapper để lưu giữ dữ liệu người dùng trong cơ sở dữ liệu.

Bây giờ, giả sử biểu mẫu được gửi trên trang web và trình điều khiển của tôi biết cần phải tạo UserEntity mới dựa trên thông tin đã gửi.

Liệu nó:

1. làm UserEntity mới() ngay tại chỗ, và chạy tất cả các phương pháp setter cần thiết theo các dữ liệu hình thức gửi, sau đó vượt qua UserEntity đến repo, người đi tới người vẽ bản đồ để chèn?

   điều khiển tạo UserEntity => Repo => Mapper => DB

2. biến các dữ liệu mẫu vào một mảng, và vượt qua nó để UserRepository người sau đó chạy UserEntity mới() và setters, và chuyển nó tới người vẽ bản đồ để chèn?

   điều khiển đi dữ liệu người dùng => Repo tạo UserEntity => Mapper => DB

3. vượt qua mảng đến UserRepository, người vượt qua mảng để mapper cho UserEntity mới và chèn?

   điều khiển đi dữ liệu người dùng => Repo qua dữ liệu người dùng => Mapper tạo UserEntity => DB

ai trách nhiệm được nó để quản lý việc tạo ra các đối tượng?

Answer 1

Đây là câu hỏi khó trả lời. Hai xu của tôi là số 1 vì một vài lý do. Đầu tiên, nó giả định bạn có xác nhận tên miền trong thực thể của bạn mà có thể rất tốt từ chối các dữ liệu được thông qua. Nếu điều đó xảy ra trong 2 hoặc 3 thì bạn đã đi sâu vài vật trước khi từ chối. Nó có thể không phải là rất nhiều bộ nhớ hoặc thời gian thực hiện về sự khác biệt giữa 2/3 và 1, nhưng nó là một sự khác biệt. Tôi cố gắng thất bại nhanh.

Thứ hai, tôi nghĩ rằng trình điều khiển biết về dữ liệu được truyền đi cũng như các đối tượng là hoàn toàn có thể chấp nhận được. Tôi đồng ý với "mô hình béo, bộ điều khiển gầy" nhưng nói rằng bộ điều khiển không thể biết về các thực thể đang làm cho bộ điều khiển quá gầy theo ý thích của tôi.

Answer 2

Tôi biết câu hỏi này là cũ, nhưng tôi nghĩ tôi sẽ ném suy nghĩ của mình ở đây vì câu trả lời duy nhất chưa được chính thức chấp nhận và điều này có thể hữu ích cho những người tìm kiếm trong tương lai. Để trả lời trực tiếp câu hỏi của bạn, tôi sẽ không nói gì ở trên. Tôi thích có một dịch vụ bổ sung, một "người quản lý" nếu bạn muốn, để môi giới sự tương tác giữa bộ điều khiển và các đối tượng repo/mapper. Mỗi mô hình có một người quản lý chuyên dụng để xử lý việc tạo, cập nhật và xóa của nó.

Controller

tôi xem xét các điều khiển như keo của ứng dụng. Chúng ta có thể tách mối quan tâm tất cả chúng ta muốn thành nhiều mảnh nhất có thể, nhưng ở đâu đó dọc theo dòng, cái gì đó phải hiểu cả mặt bên và phía mô hình, và đối tượng đó là bộ điều khiển. Điều đó đang được nói, tôi tin rằng bộ điều khiển nên gầy, do đó, công việc thực sự duy nhất của bộ điều khiển là lập bản đồ yêu cầu phản hồi. Bất kỳ loại xử lý trung gian nào cũng nên được khởi động ở một nơi khác.Trong một ứng dụng CRUD, nó khá dễ dàng để có được ngay lập tức với instantiating các đối tượng mới và kiên trì chúng trong bộ điều khiển, thậm chí nó được thực hiện nhiều hơn một lần, bởi vì nó chỉ là một vài dòng để dán. Điều gì sẽ xảy ra nếu việc tạo đối tượng không nhỏ nhặt? Tôi đang duy trì một ứng dụng với nhiều mối quan hệ phức tạp và việc tạo người dùng gửi thường đòi hỏi phải tạo ra nhiều đối tượng cùng một lúc. Điều này là không khả thi để duy trì trong môi trường điều khiển và mô hình.

tắm Dịch vụ Layers

Để xử lý điều này, tôi đã tạo thêm 2 lớp dịch vụ: FormHandler và Manager. Mỗi khi một biểu mẫu được gửi đi, nội dung biểu mẫu sẽ được gửi đến lớp xử lý biểu mẫu. Trình xử lý biểu mẫu chịu trách nhiệm hiểu dữ liệu biểu mẫu đến và chuẩn hóa dữ liệu đó. Các trình xử lý biểu mẫu sau đó có thể truyền dữ liệu đến các đối tượng người quản lý thích hợp để xử lý. Đối tượng Manager xử lý dữ liệu và cập nhật lớp miền. Họ có trách nhiệm tạo ra các mô hình, thay đổi các mô hình và duy trì chúng cho chương trình phụ trợ.

Bằng cách này, bộ điều khiển có kiến ​​thức về Yêu cầu, phản hồi, biểu mẫu (có thể, nếu khung công tác của bạn hỗ trợ tạo biểu mẫu phía máy chủ) và FormHandler. Trình xử lý biểu mẫu có kiến ​​thức về Biểu mẫu (hoặc dữ liệu biểu mẫu) và Trình quản lý. Manager có kiến ​​thức về Repository, Mapper và Model. Lưu ý, bây giờ, Người quản lý là điểm tương tác duy nhất với Mô hình và Người lập bản đồ và họ không có kiến ​​thức về dữ liệu Biểu mẫu hoặc Yêu cầu hoặc Phản hồi. Mặt khác, các trình điều khiển và trình xử lý biểu mẫu không cần phải biết về dữ liệu lớp miền hoặc sự kiên trì.

Kết luận

Với thiết kế này:

Controller -> FormHandler -> ModelManager -> Mapper

tôi đã tìm thấy tất cả các lớp học của tôi bây giờ là đơn vị kiểm chứng (thậm chí điều khiển ở một mức độ) do tách mối quan tâm là độc đáo tách ra, và điểm tương tác duy nhất là một lợi ích để tránh logic trùng lặp.

Ghi chú

Các repo trong tâm trí của tôi là chỉ để truy vấn cơ sở dữ liệu - hỏi nó nếu nó có một cái gì đó, chứ không phải tạo ra những điều mới mẻ.

Trải nghiệm của tôi trong trường hợp này là từ việc sử dụng Symfony 2 và Doctrine 2.

YMMV; ví dụ. bạn có thể thấy lớp biểu mẫu là không cần thiết, nhưng tôi thấy nó rất tiện dụng cho việc chuyển đổi dữ liệu từ dữ liệu biểu mẫu/dạng xem thành một cái gì đó mà các mô hình miền hiểu được.