Mẫu lưu trữ với lớp dịch vụ - tách quá nhiều?


8

Tôi có một trang web MVC sử dụng mẫu kho lưu trữ. Tôi không cảm thấy như tôi đang sử dụng phong cách MVC đủ, vì vậy tôi đã sẵn sàng để tái kiến ​​trúc một số trong đó. Nhưng tôi cũng muốn làm điều đó vì vậy nếu giao diện người dùng thay đổi, việc trao đổi sẽ dễ dàng hơn.

Đây là những gì tôi có hiện tại

Mô hình - một số mô hình của tôi chứa các thực thể / lớp trực tiếp. (Mô hình đăng nhập chứa lớp Khách hàng, tương quan trực tiếp với lớp Bảng / kho lưu trữ của Khách hàng) Lượt xem - một số khung nhìn của tôi chứa các truy vấn repo - tức là

_customerRepo.Query().FirstOrDefault(c => c.Login == User.Identity.Name);

Bộ điều khiển - Không phải là vấn đề lớn ở đây, bộ điều khiển gọi một số truy vấn repo và một số trong số họ cũng sử dụng một số dịch vụ để gọi repos - tức là

_customerService.GetAllCustomers()

mà gọi

_customerRepo.Query().All();

Đây là suy nghĩ của tôi:

1) Các mô hình chỉ chứa CHỈ dữ liệu cần được trình bày trên khung nhìn. Ngay cả khi tất cả các thuộc tính của bảng / đối tượng Khách hàng được hiển thị trên khung nhìn, chúng phải được ghi lại vào mô hình / lớp của riêng chúng để khung nhìn không biết gì về kiến ​​trúc cơ sở dữ liệu hoặc các đối tượng phụ trợ

2) Lượt xem chỉ nên truy cập vào các đối tượng mô hình

3) (Và đây là nơi tôi đang vật lộn trên con đường nào sẽ đi)

a) Bộ điều khiển (hoặc ở đâu đó bên phía MVC, phải là mã chuyển đổi dữ liệu đối tượng được trả về từ repo / services và chuyển đổi chúng thành các mô hình. Tôi giả sử tôi có thể đặt mã này vào một hàm tạo mô hình. Nhưng tôi đã nhận thấy rằng DI mong đợi một hàm tạo trống mặc định trong trường hợp có lỗi xác thực

b) Bộ điều khiển gọi các giao diện repo trên các phương thức được đặt tên tốt để truy xuất dữ liệu (ví dụ: _customerRepo.GetAllCustomers ()

c) Bộ điều khiển CHỈ truy cập vào một lớp dịch vụ. Lớp dịch vụ sau đó là thứ duy nhất tương tác với lớp repo.

Tôi đang cố gắng trích xuất mô hình, bộ điều khiển, dịch vụ, repo các lớp quá nhiều? Là lớp serivces quá nhiều vì nó có thể được thực hiện bởi các repos?

Cách tiếp cận được đề xuất để chuyển đổi các đối tượng / thực thể kinh doanh sang các mô hình là gì?


2
Câu trả lời của tôi cho một câu hỏi tương tự: lập trình
Eric King

1
@EricKing đây chính xác là những gì tôi đang tìm kiếm. Cảm ơn bạn! Tôi có thể bỏ phiếu để đóng câu hỏi này vì nó có thể là một bản sao của câu hỏi mà Eric có liên kết đến.
ganders

Câu trả lời:


9

Có, lớp dịch vụ là một chi phí chung nếu bạn không có logic kinh doanh nào ở đó. Kiến trúc phân lớp trông giống như một chi phí khi một lớp (trong trường hợp dịch vụ của bạn) không hoạt động nhiều. Nhưng một kiến ​​trúc lớp cung cấp khớp nối lỏng lẻo của bạn thường tốt cho việc điều chỉnh các yêu cầu trong tương lai.

Nếu bạn có thể đảm bảo rằng bạn sẽ không bao giờ cần phải làm bất cứ điều gì trong lớp dịch vụ ngoại trừ sao chép dữ liệu từ repo sang mô hình thì bạn có thể xóa lớp dịch vụ trong thiết kế của mình. Tuy nhiên, nếu ứng dụng của bạn là cơ bản thì bạn không phải lo lắng về việc thêm một lớp khác cho hiệu suất hoặc lý do khác.

Cá nhân tôi sẽ giữ lớp dịch vụ và (phụ thuộc vào công nghệ) sẽ triển khai lớp DAO / Kho lưu trữ chung.


Quan điểm này đụng độ với ddd trong đó lớp dịch vụ theo định nghĩa không có logic và logic nên có trong miền.
Esben Skov Pedersen

2
@EsbenSkovPedersen Có nhiều loại "dịch vụ" trong DDD. Dịch vụ cơ sở hạ tầng, dịch vụ ứng dụng và dịch vụ tên miền là một số ít. Mặc dù các dịch vụ Cơ sở hạ tầng và Ứng dụng không được chứa logic nghiệp vụ, các dịch vụ Miền có thể và thực hiện được.
Eric King

3

Nó phụ thuộc vào kho lưu trữ cụ thể của bạn, nhưng nói chung, tôi sẽ thêm một lớp dịch vụ lên trên các kho lưu trữ.

Tùy thuộc vào việc triển khai kho lưu trữ của bạn, chúng có thể dành riêng cho cửa hàng lưu trữ lâu bền của bạn. Nó cũng giúp thử nghiệm dễ dàng hơn và dẫn đến kiến ​​trúc hình lục giác, thay vì kiến ​​trúc xếp lớp cổ điển (mà tôi cho là có lợi), xem https://blog.8thlight.com/uncle-bob/2012/08/13/the- kiến trúc sạch.html .


Làm thế quái nào mà dịch vụ có thể được cụ thể cho các cửa hàng kiên trì? Sự trừu tượng hóa đó là những gì mà kho lưu trữ nên cung cấp. Nếu repo của bạn lộ thực thi (sql), thì bạn đang làm sai.
Eugene

-4

Để làm rõ một chút cho bạn biết bộ điều khiển là gì: MVC bắt nguồn từ khi chúng ta có các ứng dụng máy tính lớn và màn hình văn bản. Model là dữ liệu trên máy tính lớn, View là màn hình đầu cuối và Bộ điều khiển là bàn phím (nhấn # để thao tác mô hình).

Mọi thứ đã thay đổi khi ngày nay chúng ta sử dụng chuột và các nút (để Điều khiển ứng dụng) được hiển thị trên Chế độ xem.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.