Tôi nên đặt mã tạo mã HTML được chia sẻ trong dự án ASP.NET MVC ở đâu?

Question

Tôi có một giải pháp ASP.NET MVC, và tôi có một số lượng lớn các lớp HtmlHelper bên trong dự án ASP.NET MVC lấy dữ liệu và tạo ra các đoạn mã html khác nhau để hiển thị trên các trang khác nhau.

Tôi hiện phải chạy một loạt các công việc đã lên lịch và nhiều công việc trong số đó tạo email. Tôi đã chuyển tất cả các công việc này thành một dự án riêng biệt trong giải pháp (được gọi là AdminJob.csproj), nhưng bây giờ tôi thấy rằng tôi phải tạo một số email có HTML tương tự như tôi có trong các trang xem của mình. Tôi đang cố gắng để giữ cho các công việc quản trị từ có một phụ thuộc vào dự án ASP.NET MVC (như tôi muốn chạy dự án adminjob như là một dòng lệnh nếu cần thiết), và tôi cũng muốn tránh có dự án ASP.NET MVC của tôi có một sự phụ thuộc vào dự án AdminJob (vì điều đó có vẻ lạ).

Bất kỳ đề xuất nào về cách tôi có thể tránh sao chép cùng một mã hiển thị HTML trong cả dự án ASP.NET MVC và dự án AdminJob của tôi? Điều duy nhất tôi có thể nghĩ đến là tạo một dự án khác trong giải pháp có tên là "ViewHelpers" hoặc thứ gì đó như thế và di chuyển tất cả HTMLHelpers của tôi vào dự án đó để nó có thể được tham chiếu bởi cả dự án MVC và dự án AdminJob của tôi. Có vẻ như một chút quá mức cần thiết để có một dự án riêng biệt chỉ dành cho mã này, nhưng tôi không thể nghĩ ra một giải pháp khác không tạo ra sự trùng lặp.

Bất kỳ đề xuất nào khác về cách tốt hơn để thực hiện việc này và tránh bất kỳ sự trùng lặp nào?

Answer 1

Cách tôi xem đây là email là loại chế độ xem. Có một số loại chế độ xem trong ứng dụng web của tôi (html, email, pdf, rss, v.v.). Có một số triển khai của mẫu này: ActionMailer trong ruby ​​trên đường ray hoặc cổng của nó tới asp.net: MvcMailer.

Bằng cách này bạn có thể tận dụng tối đa công cụ Dao cạo trong cả ứng dụng web và email của bạn để giảm trùng lặp.

Bạn có thể lưu trữ các lượt xem của mình trong một dự án khác và thông báo cho ViewEngine của bạn về nơi cần tìm các chế độ xem (xem Views in separate assemblies in ASP.NET MVC). Tôi thấy điều này là quá mức cần thiết.

Một cách khác - cách tôi sử dụng - là có các mẫu email trong cùng một dự án với các chế độ xem khác.

Nếu bạn muốn làm cho các quan điểm bên ngoài của một ứng dụng web mà bạn có thể biên dịch các mẫu dao cạo trong một ứng dụng giao diện điều khiển bằng một trong những:

• RazorTemplates: https://github.com/volkovku/RazorTemplates
• RazorEngine: https://github.com/Antaris/RazorEngine
• với một cái gì đó như MvcMailer bạn chỉ có thể làm cho các yêu cầu curl trong các nhiệm vụ theo lịch trình của bạn. MvcMailer cần một HttpContext để chạy, do đó bạn sẽ không thể chạy nó từ một ứng dụng console. curl các hành động mvc sẽ làm việc.

Answer 2

Không loại trừ hoàn toàn ý tưởng về việc AdminJob phụ thuộc vào trang web. Điều này có thể phù hợp với bạn: How to use Razor View Engine in a console application?.

Lưu ý rằng AdminJob có thời gian biên dịch phụ thuộc vào dự án MVC không không ngăn AdminJob chạy dưới dạng ứng dụng bảng điều khiển. Điều đó có thể hoạt động tốt.

Vấn đề tôi mong đợi - ngay cả khi bạn di chuyển nội dung liên quan đến Chế độ xem vào dự án được chia sẻ— là bạn có thể thấy rằng tất cả đều bị hỏng khi chạy bên ngoài trang web. Dưới mui xe, có các phụ thuộc vào công cụ System.Web, ví dụ: HttpContext, sẽ không có thời gian chạy. Một số phụ thuộc có thể được stubbed, một số có thể không.

Đang ở trong một dự án chia sẻ riêng biệt sẽ không khắc phục được sự cố này, vì vậy tôi không nghĩ chuyển mã về bất kỳ thứ gì.

Nhưng cách tiếp cận điển hình (ví dụ 5 trong 6 công ty cuối cùng tôi đã làm việc cho) ở đây là:

Hãy quên đi ý tưởng dòng lệnh. Tạo phần công cụ quản trị của trang web. Dù bạn nghĩ rằng bạn muốn chạy từ dòng lệnh, hãy chạy nó từ một nút nhấn trên công cụ quản trị để thay thế.

PS

“Email với rất tương tự HTML như trong trang điểm của tôi” là một nút, bạn nên cắt.

Hoặc là, hoặc có thể là, giống hệt nhau với các trang xem, trong trường hợp này bạn muốn AdminJob sử dụng lại các trang xem; hay không. Trong trường hợp đó AdminJob nên có HTML của riêng nó. Trong trường hợp thứ hai này, lấy dòng mà không có thứ như HTML tương tự; nếu nó không giống nhau, thì nó khác.

Answer 3

Tôi hiểu sự cám dỗ để sử dụng lại html từ các trang web thông thường vào công cụ email của bạn. Tuy nhiên, tôi nghĩ đó là một ví dụ điển hình về kỹ thuật quá mức. Điều đó sẽ tạo ra nhiều hạn chế hơn trong thời gian dài hơn so với những lợi ích mà bạn có ngắn hạn.

Suy nghĩ về một vài điều:

HTML cho email theo thiết kế khác với HTML cho trang. Mặc dù ngày nay chúng trông giống nhau, ngày mai chúng sẽ trông khác. Bạn vừa mới nói - 'email với HTML rất giống như như tôi có trong các trang xem của tôi', bạn không nói 'với cùng một HTML chính xác'.

HTML cho email không được có bất kỳ HTML nâng cao hoặc bất kỳ JavaScript nào trong đó. Nó lý tưởng nên có CSS ​​nội tuyến và không có JavaScript. CSS tương thích với các ứng dụng email rất hạn chế. Quy tắc đánh dấu khác với cách viết tự nhiên và hiện đại của trình duyệt thông thường. Ví dụ tốt là các ứng dụng email thân thiện với các bảng, trong khi trên web hiện đại, bạn hiếm khi sử dụng các bảng ngày nay, đặc biệt nếu bạn muốn duy trì phản hồi (trình duyệt trên nhiều màn hình nền). Đọc về tất cả các giới hạn tại đây: email-standards.org

HTML cho web hiện đại không phải quá tĩnh như thông báo email phải.

Tất cả những lý do này là ý tưởng đằng sau những người gửi email thương mại phổ biến trực tuyến. Chúng giúp bạn tạo một danh sách phân phối email và họ thực hiện các nhức đầu để tạo ra HTML giới hạn thích hợp trên vai của họ. Nếu không, họ sẽ tồn tại? ai cũng có thể gửi email nhóm nếu không có sự khác biệt về đánh dấu.

Kết luận của tôi từ tất cả các điều này: nếu bạn quyết định sử dụng đánh dấu trang web của bạn cho email, bạn đang giới hạn cả hai. Bạn đang quá kỹ thuật. Nó sẽ đơn giản hơn nhiều nếu bạn không sử dụng lại đánh dấu trang thông thường vào email của mình. Tôi hiểu chúng tương tự như ngày hôm nay, nhưng chúng có thể không phải là ngày mai.

Rõ ràng, bạn nên có khả năng tạo khuôn mẫu cho công cụ email của bạn (không liên quan gì đến việc sử dụng lại đánh dấu trang web). Bạn có thể sử dụng bất kỳ công cụ templating hiện có nào, hoặc bạn có thể viết nhanh (sau khi tất cả, string.Replace() sẽ thay thế phần giữ chỗ với giá trị nếu bạn có mẫu tin nhắn HTML dưới dạng chuỗi, được tải từ tệp hoặc cơ sở dữ liệu).

Nói cách khác, để trả lời trực tiếp câu hỏi của bạn: đừng ngần ngại phân tách hai đường dẫn của trang web và email. Tránh chia sẻ các khả năng, vì chúng hầu như khác nhau. Hãy xem xét hai trong sự cô lập từ mỗi khác.