Cách tiếp cận tốt nhất để tách riêng Mô hình, Chế độ xem và Bộ điều khiển

Question

Tôi đang suy nghĩ về cách tiếp cận tốt nhất để tách riêng Chế độ xem và Bộ điều khiển Mô hình — cho Java và sử dụng Eclipse, nếu nó tạo ra bất kỳ sự khác biệt nào.

tôi sử dụng để tách MVC của mỗi loại bên trong gói riêng của mình, nhưng tôi bắt đầu suy nghĩ rằng đây không phải là phương pháp tốt nhất:

• com.company.client (khiển)
• com. company.client.model

• com.company.client.view

• com.company.another (khiển)

• com.compa ny.another.model

• com.company.another.view

• com.company.yetAnother (khiển)

• com.company.yetAnother.model
• com.company.yetAnother.view

(giả định rất nhiều gói khác nhau, mỗi người với quan điểm riêng của mình và mô hình)

tôi nghĩ về việc sử dụng:

• com.company.client
• com.company.another

• com.company.yetAnother

• com.company.model.client

• com.company.model. khác

• com.company.model.yetAnother

• com.company.view.client

• com.company.view.another
• com.company.view.yetAnother

Tôi thậm chí còn nghĩ đến việc đặt bộ điều khiển, mô hình, và xem trong các dự án khác nhau . Có lẽ nó sẽ có nhiều mô-đun hơn, và tôi sẽ chắc chắn hơn rằng chế độ xem không sử dụng bộ điều khiển, ví dụ (vì dự án bộ điều khiển sẽ bao gồm chế độ xem, nhưng không phải ngược lại).

Vậy cách tiếp cận tốt nhất để tách M, V và C là gì?

(xem xét web và máy tính để bàn ứng dụng, không chỉ web)

Answer 1

Nhiệm vụ Graal! Bạn có hai ma trận với chiều dọc (MVC) VÀ ngang (quy tắc kinh doanh) lớp ...

• tôi đã không tìm thấy một câu trả lời nghiêm ngặt
• tiếp cận đầu tiên của bạn có vẻ tốt vì mô-đun định hướng (ngoài ý muốn có thể)
• Đối với một ứng dụng nhỏ thứ hai của bạn mặc dù có thể chấp nhận được

Đối với tôi câu trả lời là một từ: phụ thuộc
Tiếp tục tìm kiếm trong "thiết kế/chiến lược gói"; "Mức độ chi tiết"

Vài đọc

• http://techdistrict.kirkk.com/2009/08/05/modularity-patterns/
• http://techdistrict.kirkk.com/2010/04/22/granularity-architectures-nemesis/

Tôi mạnh mẽ recommand này một:

• http://www.jgoodies.com/articles/patterns-and-binding-old.pdf

GOOD LUCK!

Answer 2

Bạn chỉ quan tâm đến việc "tách" Model, View và Controller như xa như đặt tên và các gói đi đâu? Điều này có vẻ là tất cả những gì bạn đang hỏi.

Tôi có xu hướng đặt ra bao bì của tôi như vậy:

• com.company.app.domain - lớp mô hình tên miền để áp dụng, chỉ cần đậu Java (thu khí và setters chỉ, rất ít nếu có logic). Điều này được sử dụng như là "mô hình" trong suốt ứng dụng và được sử dụng bởi mọi lớp ứng dụng của tôi.
• com.company.app.service - Lớp cấp dịch vụ của ứng dụng, chứa logic nghiệp vụ.
• com.company.app.web.controllers - Lớp điều khiển cho ứng dụng web của tôi. Các lớp web cụ thể khác được đặt trong các gói con khác nhau của web.
• com.company.app.dao - DAO giao diện để truy cập vào các lớp mô hình miền - tức là để lấy một người dùng từ cơ sở dữ liệu, vv

Trong mỗi trong số này, gói đôi khi được chia nhỏ theo khu vực của ứng dụng hoặc thành các nhóm nhỏ dựa trên chức năng, bất cứ điều gì có vẻ thích hợp.

Answer 3

Tôi nghĩ cũng quan trọng để xem xét cách bạn muốn sử dụng cuối cùng thực tế là bạn đã chia nhỏ các mô-đun riêng biệt trong cơ sở mã của mình. I E. Loại tiện ích nào khác ngoài chất lượng mã cơ bản mà bạn đang xem xét khai thác dựa trên lược đồ đóng gói của bạn.

Hầu hết các ứng dụng tôi làm việc theo cấu trúc bao bì sau: * .domain, * .service.subservice, * .dao, * .web.controllers. Điều này hoạt động độc đáo cho việc theo dõi các phụ thuộc tuần hoàn trong cơ sở mã và/hoặc các phụ thuộc mà dòng chảy sai (bộ điều khiển đánh dao mà không có sự gián đoạn của một dịch vụ). Nó cũng cung cấp một cấu trúc bao bì rất đơn giản, hữu ích và không gây khó chịu.

Tuy nhiên, điều này bị hỏng khi xem xét các đánh giá tác động phụ thuộc tự động. Tôi hiện đang sử dụng DependencyFinder với một chút mã tùy chỉnh để so sánh hai tệp jar trước khi QA. DependencyFinder sẽ kéo tất cả các phương thức đã sửa đổi và các phụ thuộc mức đầu tiên liên quan của chúng. Mã tùy chỉnh phải khởi động để ánh xạ các phương thức/lớp đã sửa đổi thành các chức năng nghiệp vụ và tách ra một tệp ngữ pháp graphviz để hiển thị một biểu đồ phụ thuộc dựa trên thay đổi, chức năng kinh doanh cho QA. Chúng tôi hiện đang cố gắng sử dụng các kết quả của công cụ để lập kế hoạch kiểm tra hồi quy thông minh, đặc biệt là các khuyết tật sản xuất đang chuyển sang sản xuất mà không có kiểm tra hồi quy nhiều tuần đầy đủ.

Cấu trúc thư mục bạn đề xuất sẽ làm cho trường hợp thứ hai dễ dàng hơn nhiều. Tuy nhiên, tôi cũng thấy rằng hầu hết các nhóm phát triển của tôi không thực sự quan tâm đến các phụ thuộc, vì vậy tiện ích của trình kiểm tra tự động phụ thuộc có thể khác nhau :)

Answer 4

Đây là một ví dụ sử dụng Cấu trúc phân lớp thiết kế với ba lớp (ứng dụng, tên miền, ui):

Trong chế độ xem mô hình (MVC), Mô hình sẽ ở lớp dưới, chẳng hạn như com.company.myapp.domain. Tất cả các lớp khác có thể truy cập Mô hình. Sau đó, View và Controller sẽ là com.company.myapp.ui. Điều đó có nghĩa là lớp Controller luôn nằm trong cùng một lớp với View. Đừng nhầm lẫn giữa MVC-Controller với các lớp điều khiển khác cung cấp logic ứng dụng và nằm trong lớp ứng dụng. Ví dụ: SalesController trong com.company.myapp.application, cung cấp các hoạt động của hệ thống để xử lý bán hàng.

Bây giờ bạn có thể hình dung một số dữ liệu trong mô hình của bạn (cập nhật Bán) và mô hình sau đó thông báo cho Bộ điều khiển MVC cập nhật Chế độ xem.

Lưu ý: Tất cả các kiểu máy đều ở trong lớp domain. Tất cả các Chế độ xem và Bộ điều khiển MVC đều ở trong lớp ui. Bộ điều khiển logic nghiệp vụ nằm trong lớp application. Tất nhiên bạn có thể chia nhỏ hơn ba lớp này nếu bạn có nhiều lớp với các mối quan tâm khác nhau.

Tôi hy vọng điều này sẽ hữu ích.

Answer 5

Giả sử bạn đã để đối phó với một dự án phi tầm thường, tôi nghĩ vấn đề của bạn đã hai khía cạnh để được cùng nhau xem xét thiết lập kiến ​​trúc và chất lượng mã:

• đặt tên
• đun

Để đặt tên, tôi cố gắng có sự gắn kết cao nhất trong mọi không gian tên và theo dõi Common Closure Principle và Common Reuse Principle.

Để mô đun hóa, tôi cố gắng sử dụng mô-đun cho mọi vấn đề chính về kiến ​​trúc của dự án và đặt tên cho các gói của nó một cách thuận tiện.

MVC là mẫu mô-đun trình bày nhằm phân tách cách luồng điều khiển mô-đun trình bày, mô hình dữ liệu dựa trên đó và logic liên quan đến chế độ xem.

Trong IDE java của tôi (ví dụ: Eclipse), tôi sử dụng một dự án cho mỗi mô-đun, vì vậy mô-đun web sẽ là một mô-đun dự án và máy tính để bàn sẽ là một dự án khác.Trong một dự án web, ví dụ tôi có một tiền tố phổ biến, chẳng hạn như:

com.mycompany.app.web 

và trong đó tôi có một .controllers (hoặc hành động) hậu duệ, một .models hậu duệ và vân vân.

com.mycompany.app.web.models 
com.mycompany.app.web.actions 

Nếu tôi sử dụng cơ sở dữ liệu, tôi dựa vào mô-đun DAO, một dự án khác. Mô-đun DAO không có bản trình bày nên không có cách tiếp cận MVC. Nó tồn tại các đối tượng Domain, vì vậy có lẽ nó dựa vào một mô-đun Domain. Trong các module tôi sử dụng các tiền tố như sau:

com.mycompany.app.domain 
com.mycompany.app.dao 

Tôi cố gắng để không nhầm lẫn Mẫu trong MVC với ứng dụng miền; chúng không giống nhau.

Một sai lầm phổ biến khác là gây nhầm lẫn Bộ điều khiển với Logic nghiệp vụ; logic nghiệp vụ nên được đặt vào một mô-đun và được chia sẻ giữa các mô-đun trình bày, bộ điều khiển trong vùng tên của mô-đun trình bày (web hoặc máy tính để bàn).

Một mô hình (trong MVC, một mô hình xem) là một đối tượng được sử dụng bởi một cái nhìn để hiển thị một cái gì đó cho người sử dụng: nó có thể chứa một, một sự kết hợp hoặc một bộ sưu tập của miền đối tượng. Bộ điều khiển sử dụng các mô đun có sẵn (DAO, v.v.) để tạo chế độ xem Kiểu và sau đó chuyển đến Xem.

Xem thì có thể chỉ dựa vào mẫu của nó (chỉ một, rõ ràng được tạo ra bởi bộ điều khiển) và đề nghị cho các mô hình chỉ để các bộ điều khiển (chỉ có thể xây dựng mô hình). Xem, đặc biệt là cho các bản trình bày trên web, thường được mã hóa theo sự pha trộn các ngôn ngữ, vì vậy một phần của mã có thể vẫn nằm ngoài các quy ước đặt tên.

Answer 6

Suy nghĩ về cách bạn phát triển. Bạn có phát triển cho mỗi Controller/Model/View không? Hay bạn phát triển cho mỗi module. Rất có thể bạn đang phát triển trên một mô-đun chứ không phải trên một lớp MVC. Vì vậy, do đó tôi nghĩ rằng có nằm câu trả lời của bạn. Cố gắng giữ cho tên gói của bạn gần với các mô-đun mà hệ thống của bạn đại diện (mà bạn đã làm). Không cần hiển thị cho bạn các lựa chọn kiến ​​trúc trong tên gói của bạn.

Hiển thị tên mô-đun và các vấn đề về miền trong gói của bạn, tạo một codebase duy trì và nhất quán.