Kiến trúc tốt nhất cho ứng dụng ASP.NET WebForms


10

Tôi đã viết một cổng thông tin ASP.NET WebForms cho một khách hàng. Dự án có loại phát triển hơn là được lên kế hoạch và cấu trúc đúng đắn ngay từ đầu. Do đó, tất cả các mã được trộn với nhau trong cùng một dự án và không có bất kỳ lớp nào. Hiện tại khách hàng hài lòng với chức năng, vì vậy tôi muốn cấu trúc lại mã sao cho tôi sẽ tự tin về việc phát hành dự án. Vì dường như có nhiều cách khác nhau để thiết kế kiến ​​trúc, tôi muốn có một số ý kiến ​​về cách tiếp cận tốt nhất để thực hiện.

CHỨC NĂNG

Cổng thông tin cho phép quản trị viên cấu hình các mẫu HTML. Các "đối tác" được liên kết khác sẽ có thể hiển thị các mẫu này bằng cách thêm mã IFrame vào trang web của họ. Trong các mẫu này, khách hàng có thể đăng ký và mua sản phẩm. Một API đã được triển khai bằng WCF cho phép các công ty bên ngoài cũng giao tiếp với hệ thống. Phần Quản trị viên cho phép Quản trị viên định cấu hình các chức năng khác nhau và xem báo cáo cho từng đối tác. Hệ thống gửi hóa đơn và thông báo qua email cho khách hàng.

KIẾN TRÚC HIỆN TẠI

Hiện tại nó đang sử dụng EF4 để đọc / ghi vào cơ sở dữ liệu. Các đối tượng EF được sử dụng trực tiếp trong các tệp aspx. Điều này đã tạo điều kiện cho sự phát triển nhanh chóng trong khi tôi đang viết trang web nhưng có lẽ không thể chấp nhận được việc giữ nguyên như vậy vì nó liên kết chặt chẽ db với UI. Logic nghiệp vụ cụ thể đã được thêm vào các lớp một phần của các đối tượng EF.

CÂU HỎI

Mục tiêu của tái cấu trúc sẽ là làm cho trang web có thể mở rộng, dễ bảo trì và bảo mật.

  1. Những loại kiến ​​trúc sẽ là tốt nhất cho điều này? Vui lòng mô tả những gì nên có trong mỗi lớp, liệu tôi có nên sử dụng mẫu DTO's / POCO / Active Record hay không, v.v.

  2. Có cách nào mạnh mẽ để tự động tạo DTO's / BO để mọi cải tiến trong tương lai sẽ được thực hiện đơn giản mặc dù có thêm các lớp không?

  3. Sẽ có lợi khi chuyển đổi dự án từ WebForms sang MVC?


1
Phát hành sớm, thường xuyên phát hành. Tôi đề nghị khách hàng của bạn có thể không quan tâm lắm nếu bạn không có vấn đề kinh doanh hữu hình để trình bày (ví dụ: không an toàn). Có lẽ bạn nên dọn dẹp một chút (đảm bảo rằng nó có thể mang theo được) và phát hành, sau đó thực hiện điều này như một sáng kiến ​​lâu dài - để biến thành MVC hoặc tương tự.
gahooa

2
Đừng thay đổi công nghệ dự án làm việc của bạn thành công nghệ xyz mới chỉ vì nó ở đó, đặc biệt nếu dự án của bạn hoạt động tốt như hiện tại. Nếu nó đang hoạt động đừng phá vỡ nó. Kinh doanh không quan tâm đến mã. Chức năng là tất cả những gì quan trọng vào cuối ngày.
NoChance

ok đó là sự thật, tuy nhiên mối quan tâm của tôi là, một khi nó được phát hành, nó sẽ khó tái cấu trúc hơn vì nguy cơ phá vỡ nó khi cổ phần cao hơn nhiều. Vì vậy, chúng tôi sẽ bị mắc kẹt với mã không thể duy trì và khó gỡ lỗi hơn, v.v. Tôi đã cố gắng học / chuyển đổi sang MVP nhưng điều đó có vẻ như quá nhiều công việc. Cho đến nay tôi mới chuyển đổi nó thành các lớp DAL, Domain, UI có tổ chức hơn nhưng vẫn cho phép RAD không thể tránh khỏi sẽ cần trong khi dự án còn non trẻ. Một ngày nào đó nếu cần tôi có thể mở rộng sang MVP hoặc MVC tôi cho rằng - sau khi tôi có đủ thời gian để tìm hiểu cách thức hoạt động của tất cả.
người đàn ông stack

Điều vẫn cảm thấy lộn xộn là: 1) Các đối tượng EF trong UI (mã phía sau các tệp trong lớp UI)
stack man

(2) Logic nghiệp vụ trong các đối tượng EF mở rộng phải đi trong lớp DAL (không nhận ra các lớp một phần phải nằm trong cùng một cụm) (3) Logic nghiệp vụ trong các tệp aspx.cs trong lớp UI. Tuy nhiên, dường như thường có sự thỏa hiệp khi nói đến kiến ​​trúc nhưng đây chắc chắn là một bước tiến. Tôi cảm thấy rằng điều này được chấp nhận cho lần phát hành đầu tiên và khi thời gian trôi qua, chúng tôi có thể đánh giá lại cách tiếp cận của chúng tôi. Cảm ơn sự giúp đỡ của mọi người. Thật tốt khi có được một chút định hướng vì khu vực này rất chủ quan.
người đàn ông stack

Câu trả lời:


5

Mẫu ASP.NET MVP là kiến ​​trúc tốt nhất cho ứng dụng webforms ASP.NET dài hạn . Nó đang đi vào hoạt động với khái niệm "phân tách mối quan tâm", thực tế là một xu hướng đằng sau các mẫu MV *.

Câu hỏi tại sao nên sử dụng nó? - được đề cập chi tiết trong bài này - ASP.NET MVP


Vấn đề là, nó sẽ đòi hỏi rất nhiều công việc để cấu trúc lại dự án thành MVC ... nếu tôi giữ nó dưới dạng ứng dụng WebForms với Lớp miền (mã đầu tiên, POCO), Lớp truy cập dữ liệu (chỉ ngữ cảnh db) và UI, sẽ Bạn coi đây là một thiết kế chấp nhận được cho sản xuất? Vào một ngày sau đó, chúng tôi có thể xem xét chuyển đổi nó sang MVC tôi cho rằng.
stack man

Vâng, đó là một mẫu MVP (model-view-presenter) và KHÔNG phải là một MVC (model-view-controller).
Yusubov

1
oh xin lỗi - tôi đọc sai Cảm ơn bạn - Tôi sẽ đọc về thiết kế MVP.
người đàn ông stack

không vấn đề gì, tôi hy vọng bạn sẽ tìm thấy những gì bạn tìm kiếm :)
Yusubov

Có vẻ như việc chuyển đổi sang MVP cũng sẽ là một thay đổi lớn. Máy khách muốn phát hành sớm, vì vậy bạn có nghĩ rằng kiến ​​trúc DAL / DA / UI được đề cập ở trên (mặc dù không lý tưởng như MVP) sẽ được chấp nhận cho loại ứng dụng này không? Sau khi phát hành, chúng tôi có thể xem xét chuyển sang MVP trong v2.
người đàn ông stack

1
  1. Sử dụng mẫu MVP cho riêng biệt và logic và giao diện người dùng, vì vậy trong tương lai bạn có thể chuyển sang một công nghệ UI khác sử dụng lại logic hiện có
  2. Sử dụng mẫu kho lưu trữ giữa BL và DAL để bạn có thể thay đổi thành bất kỳ RDBS nào sử dụng lại logic nghiệp vụ
  3. mang các lớp riêng biệt (dll) cho BO và DAL đang giảm thiểu bảo trì.

Không chắc chắn tại sao bất cứ ai xuống bỏ phiếu câu hỏi này. Thành thật mà nói, đây là câu trả lời ngắn gọn nhất. +1
Greg Burghardt

0

Như ElYusubov đã đề cập, mẫu MVP có thể rất tuyệt.

Khái niệm chính là tước bỏ hầu hết hoặc tất cả logic của bạn từ phía sau mã. Logic không nên bị ràng buộc vào một trang. Điều gì nếu bạn cần sử dụng lại logic từ một trang trong một trang khác? Bạn sẽ bị cám dỗ để sao chép và dán. Nếu bạn đang làm điều này thì dự án của bạn sẽ trở nên có thể duy trì.

Vì vậy, đối với người mới bắt đầu, tái cấu trúc logic của bạn ra khỏi mã phía sau và đặt nó vào một lớp nghiệp vụ. Nếu bạn quản lý để đưa tất cả logic ra khỏi mã phía sau thì bạn có thể triển khai các giao diện cần thiết để trở thành một MVP thực sự.

Cũng đảm bảo quyền truy cập dữ liệu của bạn tách biệt với logic kinh doanh của bạn. Tạo một lớp dữ liệu và cũng bắt đầu tái cấu trúc vào đầu đó. Vì bạn đang sử dụng EF4 nên đây không phải là vấn đề vì EF nên có kết thúc này riêng biệt. Bạn sẽ có thể dễ dàng di chuyển tất cả các tệp EF của mình sang dự án khác và chỉ cần thêm một tham chiếu đến các dự án cần nó. Lợi ích được thêm vào, bạn có thể cần tham chiếu mô hình dữ liệu của mình trong các dự án khác.

Để tránh bị choáng ngợp, hãy tái cấu trúc từng chút một. Bất cứ khi nào bạn chạm vào một đoạn mã, hãy cân nhắc việc tái cấu trúc mã xung quanh nó. Nếu bạn làm điều này, theo thời gian dự án của bạn có thể trở nên dễ bảo trì hơn.

Biên tập

Bạn đã hỏi về việc có mã đằng sau kế thừa một lớp logic kinh doanh. Điều này không thể được thực hiện bởi vì mã đằng sau trang "is-a". C # không cho phép nhiều kế thừa, vì vậy lớp mã phía sau có thể vừa là trang vừa là đối tượng tùy chỉnh. Bạn cần khái niệm tách ra logic. Có lẽ trường hợp mã trong mã phía sau của bạn đang làm nhiều việc khác nhau. Một lớp nên làm một việc và một điều duy nhất. Hãy thử và suy nghĩ về cách bạn có thể rút ra chức năng hiện có. Ví dụ: giả sử bạn có trang đăng ký và bạn đang thu thập thông tin người dùng. Bạn có thể có một nút được gọi là đăng ký và một sự kiện nhấp chuột liên quan đến nút đó. Trong trường hợp đó, bạn đang lưu thông tin người dùng và thực hiện bất kỳ xử lý nào bạn cần. Bạn có thể tạo một đối tượng Đăng ký để xử lý tất cả logic đó.

Đây không chỉ là một sự phân tách rõ ràng hơn mà còn có thể là một cách để tự ghi lại mã của bạn. Khi ai đó đọc mã của bạn, họ thấy bạn gọi một đối tượng Đăng ký để bạn biết chính xác những gì đang diễn ra.

Nếu bạn muốn tuân thủ nghiêm ngặt mẫu MVP, thay vì chuyển các tham số cho đối tượng Đăng ký, mã phía sau sẽ triển khai giao diện. Việc triển khai giao diện về cơ bản sẽ ánh xạ tất cả các đối tượng xem (trường văn bản, v.v.) sang giao diện. ví dụ: chuỗi công khai FirstName {get {return txtFirstName.Text; }}

Khi đã xong, bạn có thể chuyển trang đến đối tượng Regisration

Đăng ký.RegisterUser (này);

Và phương thức RegisterUser này sẽ lấy giao diện làm tham số

công khai bool RegisterUser (người dùng IUser) {user.FirstName ...}

giao diện công cộng IUser {chuỗi công khai FirstName; }

Nếu MVP này nghe có vẻ khó hiểu, chỉ cần tập trung vào tái cấu trúc và biết điểm của tất cả điều này là để tối đa hóa việc tái sử dụng mã. Không có từ khi lặp lại chính mình. Đó là hiệu trưởng DRY .


Cảm ơn lời khuyên hữu ích của bạn. Vâng, tôi chắc chắn đã có một chút choáng ngợp với điều này. Dường như với tôi rằng MVC sẽ là mẫu tốt nhất để sử dụng nhưng MVP sẽ dễ đạt được hơn và sẽ là mẫu tốt nhất tiếp theo. Tôi đã luôn sử dụng mã phía sau các tệp để luôn gãi đầu về cách logic kinh doanh có thể tách rời khỏi bản trình bày ... vì vậy tôi về cơ bản có thể di chuyển các tệp .aspx.cs của mình sang lớp miền và có câu lệnh kế thừa trong aspx ? Chắc chắn kết thúc với 3 lớp sẽ khiến tôi cảm thấy thoải mái khi phát hành phiên bản đầu tiên - sau đó tôi có thể cải thiện nó từ đó.
người đàn ông xếp chồng

Tôi sẽ trả lời bình luận của bạn trong câu trả lời của tôi. Vui lòng nêu lên câu trả lời của tôi nếu bạn thấy nó hữu ích
coder
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.