Tại sao mọi người đặt bộ điều khiển trong một thư mục và chế độ xem trong một thư mục khác?

Tôi đã sẵn sàng để vượt qua asp và vào một khung mvc, asp.net mvc hoặc nancy. Bất cứ nơi nào tôi đi, tôi thấy các thư mục cho bộ điều khiển / mô-đun và thư mục để xem. Đây có phải chỉ là một phản xạ của pavlovian về việc dọn dẹp mọi thứ theo loại, hoặc có một sự khôn ngoan sâu sắc hơn hoạt động? Tôi có một dự án bằng chứng nhỏ, nơi tôi lưu trữ các tệp mà tôi có khả năng mở cùng nhau, một sự thoải mái đáng kể. Vì các tệp này cũng có khả năng gọi cho nhau, nên chúng có thể làm như vậy với các liên kết tương đối ngắn hơn, ít giòn hơn. Mẫu này bị thách thức bởi mvc, vì đường dẫn thư mục không còn tự động tương ứng với đường dẫn url và, trong asp.net mvc, các mẫu dự án và định tuyến thực thi các khung nhìn \ controls \ schism.

Đây trang microsoft giới thiệu các khái niệm về khu vực này. Nó có thể được đọc như là một sự thừa nhận về việc các ứng dụng lớn khó sử dụng trở nên như thế nào vì sự tách biệt giả tạo này.

Mọi người sẽ phản đối "phân tách mối quan tâm", nhưng việc phân tách mối quan tâm đã đạt được bằng cách có các tệp nguồn riêng biệt. Đối với tôi, không có lợi ích cụ thể nào, từ việc lấy các tệp nguồn này được liên kết chặt chẽ và gửi chúng đến các đầu đối diện của cấu trúc thư mục?

Có ai khác chiến đấu với điều này? Lời khuyên nào?

Tôi muốn nói rằng đó là lập trình sùng bái hàng hóa , nhưng có những lý do kỹ thuật cho cấu trúc này. Asp.Net MVC đã có một quy ước về cách tiếp cận cấu hình với hầu hết mọi thứ. Theo mặc định, công cụ xem dao cạo tìm kiếm Viewsthư mục để giải quyết chế độ xem nào sẽ trả về từ bộ điều khiển. Tuy nhiên, có một số hack để có được cấu trúc dự án khác và Microsoft thậm chí còn cung cấp một tính năng MVC có tên là Area để cho phép chúng tôi tạo cấu trúc dự án lành mạnh hơn. Bạn cũng có thể triển khai công cụ xem của riêng mình để chỉ định nơi cần tìm chế độ xem.

Tại sao tôi nói rằng đó là chương trình sùng bái hàng hóa và bạn đã đúng về điều này? Chú Bob đã thuyết phục tôi rằng cấu trúc thư mục của dự án không nên nói với tôi rằng đó là một ứng dụng MVC. Nó sẽ cho tôi biết rằng đó là mặt tiền cửa hàng, hoặc hệ thống yêu cầu tắt thời gian, hoặc bất cứ điều gì. Cấu trúc và kiến ​​trúc cấp cao sẽ cho chúng ta biết điều này là gì chứ không phải nó được thực hiện như thế nào .

Nói tóm lại, tôi tin rằng bạn đúng về điều này, nhưng bất kỳ cấu trúc thư mục nào khác chỉ đơn giản là đang chống lại khung công tác và tin tưởng tôi khi tôi nói rằng bạn không muốn cố gắng làm cho khung Asp.Net MVC làm một cái gì đó Được thiết kế để làm. Thật đáng tiếc rằng nó thực sự không thể cấu hình nhiều hơn.

Để nhanh chóng giải quyết các mối quan tâm về kiến ​​trúc, tôi vẫn tin rằng các mô hình kinh doanh (kinh doanh, không phải xem) và DAL nên sống trong một dự án / thư viện riêng được gọi từ ứng dụng MVC của bạn.

Chỉ là bộ điều khiển thực sự được kết hợp rất chặt chẽ với chế độ xem và có khả năng được sửa đổi cùng nhau. Tất cả chúng ta đều khôn ngoan khi nhớ sự khác biệt giữa khớp nối thông qua sự phụ thuộc và khớp nối logic. Chỉ vì mã đã bị tách rời các phụ thuộc của nó không làm cho nó ít được ghép nối một cách hợp lý.

Dù lý do là gì, đây là thực hành kém. Nó rất chống OO vì các gói hoặc thư mục (bất cứ điều gì bạn muốn gọi chúng), nên có sự phụ thuộc lẫn nhau yếu. Các lớp (hoặc tệp) bên trong chúng nên có sự phụ thuộc lẫn nhau mạnh mẽ.

Bằng cách ném tất cả các khung nhìn vào một thư mục và tất cả các bộ điều khiển trong một thư mục khác, bạn đang tạo hai gói với khớp nối rất chặt chẽ. Điều này đi ngược lại nguyên tắc có các phụ thuộc liên gói yếu.

Một khung nhìn và một bộ điều khiển là hai nửa của một tổng thể và nên thuộc về nhau. Bạn sẽ không có một lần rút tủ cho vớ bên trái và một lần rút khác cho vớ bên phải.

Để trả lời 'Tại sao mọi người ...?' câu hỏi: Dưới đây là một số lý do tiềm năng, mặc dù tôi không hoàn toàn chắc chắn sự kết hợp nào của chúng là nguyên nhân thực sự, vì đây thực sự là một câu hỏi chủ quan

• Để tái tạo kiến ​​trúc logic (mô hình, khung nhìn, bộ điều khiển) với cấu trúc thư mục và không gian tên phù hợp

• Không theo quy ước & thuận tiện để làm theo mẫu dự án ASP.net MVC

• Để nhóm theo không gian tên, vì Controllers/thư mục sẽ dẫn đến một .Controllerskhông gian tên

• Có thể kích hoạt một số tình huống trong DI / IoC trong đó các lớp trình điều khiển chỉ được truy vấn / quét từ một không gian tên có chứa / kết thúc với 'Bộ điều khiển' (điều này có thể sai)

• Để cho phép các mẫu T4 quét và tạo mô hình & bộ điều khiển để tạo chế độ xem

Bạn luôn có thể tạo và làm theo quy ước của riêng bạn nếu nó có ý nghĩa với dự án của bạn, không ai có thể / sẽ ngăn cản bạn. Nhưng hãy lưu ý rằng nếu bạn làm việc trong một dự án lớn và / hoặc nhóm lớn, thì quy ước mặc định mà mọi người đều biết có thể là một lựa chọn tốt hơn (mặc dù không nhất thiết phải là một dự án đúng!)

Nếu quy ước của bạn dễ thực hiện hơn và không cản trở năng suất, thì bằng mọi cách hãy làm điều đó! và thậm chí có thể viết về nó một hoặc hai bài đăng trên blog để xã hội hóa nó với cộng đồng nhà phát triển và nhận phản hồi

Một lý do để giữ các khung nhìn và bộ điều khiển trong các thư mục riêng biệt là khi bạn có các nhà phát triển front end và back end làm việc trong một dự án. Bạn có thể ngăn các nhà phát triển giao diện truy cập mã mặt sau (ví dụ: để hỗ trợ tuân thủ PCI, hạn chế người có quyền truy cập vào mã nhạy cảm).

Một lý do khác là để làm cho việc có "chủ đề" dễ dàng hơn và tắt tất cả các mẫu bằng cách thực hiện một thay đổi nhỏ cho đường dẫn xem.

Lý do thứ ba là để có một mẫu thư mục đơn giản khi chỉ định các khung nhìn trong khung MVC. Việc chỉ định thư mục con và tệp sẽ dễ dàng hơn là một đường dẫn dài đến mỗi chế độ xem.

"Khớp nối chặt chẽ" duy nhất nên là:

1. Các biến được gửi vào khung nhìn bởi bộ điều khiển.
2. Hình thành các trường hoặc hành động trong dạng xem, gửi lại cho bộ điều khiển.

Tôi sử dụng một bộ điều khiển chung và cố gắng giữ các tên biến trong chế độ xem chung, để nhiều chế độ xem có thể sử dụng cùng một bộ điều khiển và nhiều bộ điều khiển có thể sử dụng cùng một chế độ xem. Vì lý do này, tôi thích giữ quan điểm hoàn toàn riêng biệt. Mô hình là nơi bạn có thể phân biệt từng "vật" trong ứng dụng của mình - chúng có thể là các đối tượng với danh sách các thuộc tính và phương thức để truy cập / sửa đổi các thuộc tính này.

Đối với mã được liên kết chặt chẽ, một cách tiếp cận có thể phù hợp với bạn là giữ tất cả các tệp là một phần của gói hoặc "mô-đun" cùng nhau trong một thư mục được đặt tên. Sau đó, bạn có thể sử dụng tập lệnh để sao chép hoặc "biên dịch" các mẫu thô của bạn vào thư mục "lượt xem" chính. Ví dụ:

    lib/my-namespace/my-package/
        -> controllers/
        -> models/
        -> views/
            -> theme/
               -> template-name1
    app/compiled_views/theme/
        -> url/path/template-name1

Thật không may, nếu bạn muốn thay đổi cấu trúc của một chủ đề hiện có, có nhiều kết nối trong và ngoài các thư mục gói để cập nhật các khung nhìn.

Xem xét rằng các lượt xem chỉ là một cách để định dạng dữ liệu, cho dù đó là json, xml, csv hoặc html. Điều này đặc biệt hữu ích nếu bạn muốn ứng dụng của mình cũng hoạt động như một API. Cố gắng tách rời chế độ xem khỏi dữ liệu, bằng cách sử dụng tên biến chung, để bạn có thể sử dụng cùng một mẫu cho nhiều bộ điều khiển hoặc mô hình (hoặc sử dụng bao gồm để giảm thiểu số lượng mã bạn cần duy trì).

Không nhất thiết là tất cả mọi người làm điều này. Ví dụ, khung Django của python có khái niệm về một ứng dụng, trong đó các mô đun con của ứng dụng của bạn nằm trong các thư mục của riêng chúng với các mô hình và khung nhìn và mẫu riêng của chúng (các khung nhìn là những gì Django gọi là bộ điều khiển). Tôi tình cờ thích cách làm việc đó bởi vì điều đó có nghĩa là tôi có thể dễ dàng đóng gói một "ứng dụng" và sử dụng lại nó trong các dự án chỉ bằng cách đưa nó vào danh sách ứng dụng trong cài đặt dự án của tôi. Nó cũng dễ dàng hơn để tìm ra nơi các bộ phận khác nhau. Nếu tôi nhìn vào tệp urls.py và thấy một cái gì đó giống như url(r'^users/', include('my_site.users.urls')), tôi biết rằng mô-đun my_site.userschứa tất cả các mã xử lý người dùng. Tôi biết để xem xét các mô-đun my_site.users.viewsvà my_site.users.modelskhi tôi muốn xem cách người dùng được tạo và xác thực. Tôi biết rằng tất cả các tuyến đường của tôi được xác định trong my_site.users.url.

Ngoài ra, nếu nó đủ chung chung, tôi có thể sử dụng mô-đun đó trong các trang web khác chỉ bằng cách thay đổi cấu hình hoặc đóng gói nó dưới dạng thư viện và xuất bản dưới dạng OSS.

Hãy nhớ rằng đó là cách được Microsoft khuyến nghị để giữ các bộ điều khiển và chế độ xem trong thư mục khác nhau, vì vậy nhiều người sẽ tuân theo cấu trúc được đề xuất,

1. Một lý do có thể là các bộ điều khiển luôn không có mối quan hệ 1-1 với các khung nhìn, đặc biệt là các khung nhìn một phần có thể được chia sẻ giữa các bộ điều khiển.
2. Một lý do khác có thể là khi dự án của bạn phát triển, bạn có thể muốn kéo các bộ điều khiển và kiểm tra đơn vị sang (các) dự án khác, nhưng thật khó để làm điều tương tự cho các lượt xem cộng với lượt xem / js / css khi chúng tham chiếu lẫn nhau.

Đã nói rằng có nhiều bài viết về việc làm theo cách của bạn, chẳng hạn như điều này .

Đối với hồ sơ

Tại sao tôi nói rằng đó là chương trình sùng bái hàng hóa và bạn đã đúng về điều này? Chú Bob đã thuyết phục tôi rằng cấu trúc thư mục của dự án không nên nói với tôi rằng đó là một ứng dụng MVC. Nó sẽ cho tôi biết rằng đó là mặt tiền cửa hàng, hoặc hệ thống yêu cầu tắt thời gian, hoặc bất cứ điều gì. Cấu trúc và kiến ​​trúc cấp cao sẽ cho chúng ta biết điều này là gì chứ không phải nó được thực hiện như thế nào.

Câu hỏi: Ai có quyền truy cập vào mã?. Lập trình viên. Người dùng cuối có quan tâm đến mã không? Không. Và, những gì một lập trình viên làm, mã. Hay cụ thể hơn, các lớp dựa trên các loại (bộ điều khiển, dịch vụ, mô hình, v.v.). Vì vậy, nó có ý nghĩa và thật dễ dàng để gỡ lỗi một mã, nếu bạn có thể tìm thấy một mã dựa trên loại mã, thay vì trong hành vi của mã. Thêm vào đó, giả sử một dự án nhóm, một người chịu trách nhiệm về bộ điều khiển, một mô hình khác, một dao khác và một khung nhìn khác. Thật dễ dàng để tách dự án thành các phần. Một mã tốt là một mã dễ gỡ lỗi, không phải là mã đường cú pháp. Chú Bob lại sai rồi.

Cố gắng bắt chước hành vi của dự án (một mặt tiền cửa hàng) là sùng bái hàng hóa.