ASP.NET MVC 프로젝트에서 공유 HTML 생성 코드는 어디에 두어야합니까?

Question

저는 ASP.NET MVC 솔루션을 보유하고 있으며 데이터를 가져 와서 다양한 페이지에 표시 할 HTML 스 니펫을 생성하는 ASP.NET MVC 프로젝트 내에 많은 수의 HtmlHelper 클래스가 있습니다.

이제 일정 잡힌 작업을 실행해야하며 이러한 작업 중 많은 작업이 이메일을 생성합니다. 이러한 모든 작업을 솔루션의 별도 프로젝트 (AdminJob.csproj라고 함)로 옮겼지만 지금은보기 페이지에있는 것과 매우 유사한 HTML로 많은 수의 전자 메일을 생성해야합니다. 관리자 작업을 ASP.NET MVC 프로젝트에 의존하지 않도록 유지하려고합니다. (필요한 경우 adminjob 프로젝트를 명령 줄로 실행하고 싶습니다.) 또한 ASP.NET MVC 프로젝트를 피하기를 원합니다. AdminJob 프로젝트에 대한 의존성이 있습니다 (이상한 것처럼 보입니다).

내 ASP.NET MVC 프로젝트와 AdminJob 프로젝트에서 동일한 HTML 렌더링 코드를 복제하지 않도록하는 방법에 대한 제안 사항은 무엇입니까?

내가 생각할 수있는 유일한 해결책은 "ViewHelpers"라고하는 솔루션에서 다른 프로젝트를 만들거나 내 HTMLHelpers를 모두 해당 프로젝트로 옮겨서 내 MVC 프로젝트와 AdminJob 프로젝트에서 모두 참조 할 수 있도록하는 것입니다. 이 코드에 대해 별도의 프로젝트를 갖는 것은 다소 과잉이라고 생각되지만 중복을 생성하지 않는 다른 솔루션은 생각할 수 없습니다.

이 작업을 수행하고 중복을 피하는 더 좋은 방법에 대한 다른 제안 사항이 있습니까?

Answer 1

내가 보는 방식은 이메일이보기 유형입니다. 내 웹 앱 (html, 이메일, pdf, rss 등)에 여러 가지보기 유형이 있습니다. 이 패턴의 구현은 여러 가지가 있습니다. 레일상의 루비에 ActionMailer 또는 asp.net에 대한 포트 : MvcMailer.

이렇게하면 중복을 줄이기 위해 웹 응용 프로그램과 전자 메일 모두에서 Razor 엔진을 최대한 활용할 수 있습니다.

다른 프로젝트에서보기를 호스팅하고 ViewEngine에게보기를 찾을 위치를 알릴 수 있습니다 (Views in separate assemblies in ASP.NET MVC 참조). 나는 이것이 과잉이라고 판단한다.

내가 사용하는 또 다른 방법은 같은 프로젝트에 다른보기가있는 이메일 템플릿을 만드는 것입니다.

당신은 웹 응용 프로그램의 외부 전망이 이들 중 하나를 사용하여 콘솔 응용 프로그램에서 면도기 템플릿을 컴파일 할 수 있습니다 렌더링 할 경우

• RazorTemplates : https://github.com/volkovku/RazorTemplates
• RazorEngine : https://github.com/Antaris/RazorEngine
• 과를 MvcMailer와 마찬가지로 예약 된 작업에서 컬 요청 만 할 수 있습니다. MvcMailer는 콘솔 앱에서 실행할 수 없도록 HttpContext를 실행해야합니다. mvc 액션이 작동 할 것입니다.

Answer 2

AdminJob이 웹 사이트에 의존한다는 생각을 완전히 배제하지 마십시오. 이것은 당신을 위해 일할 수도 있습니다 : How to use Razor View Engine in a console application?.

MVC 프로젝트에 컴파일 타임 종속성이있는 AdminJob은 이 아니고이 아니기 때문에 AdminJob이 콘솔 앱으로 실행되지 않습니다. 그건 잘 될 수있어.

뷰 관련 항목을 공유 프로젝트로 옮기는 경우에도 웹 사이트 외부에서 실행될 때 런타임에 모두 중단된다는 것을 알 수 있습니다. 후드에는 System.Web 항목에 대한 의존성이 있습니다 (예 : HttpContext, 런타임시 null이됩니다. 일부 종속성은 스터브되고 일부는 종속성을 가질 수 없습니다.

별도의 공유 프로젝트에 있어도이 문제는 전혀 해결되지 않으므로 코드 이동에 대해서는별로 도움이되지 않습니다.

그러나 일반적인 접근 방법은 여기 (5 I가 작업 한 마지막 6 개 기업 중 즉)입니다 :

명령 줄 생각을 잊어 버려요. 관리 도구를 웹 사이트의 일부로 만듭니다. 명령 줄에서 실행하고 싶다고 생각하는 것이면 관리 도구의 푸시 버튼에서 실행하십시오.

"내보기 페이지에서 매우 유사한 HTML과 이메일"

PS는 절단해야 매듭이다.

보기 페이지에 동일이 있거나이 경우 AdminJob에서보기 페이지를 다시 사용하도록 할 수 있습니다. 그렇지 않다. 이 경우 AdminJob에는 자체 HTML이 있어야합니다. 이 두 번째 경우에는 '유사한'HTML과 같은 것이 없다는 것을 명심하십시오. 똑같지 않으면 다르다.

Answer 3

나는 정기적 인 웹 사이트 페이지에서 html을 이메일 엔진으로 재사용하려는 유혹을 이해합니다. 그러나, 나는 그것이 over-engineering의 좋은 예라고 생각한다. 그러면 단기간에 얻을 수있는 이점보다 장기적인 한계가 훨씬 더 많이 생길 것입니다.

가지의 커플에 대해 생각 : 이메일에 대한

HTML 페이지의 HTML에서 다른 디자인입니다. 오늘은 비슷해 보이지만 내일은 달라 보일 것입니다. 당신이 방금 말했듯이 - 매우 비슷한 HTML을 가진 의 이메일을 보았습니다. 내보기 페이지에있는 것처럼과 똑같은 HTML을 사용하지 않았습니다.

전자 메일 용 HTML에는 고급 HTML 또는 JavaScript가 없어야합니다. 그것은 이상적으로 인라인 CSS와 JavaScript가 없어야합니다. 이메일 클라이언트와 호환되는 CSS는 매우 제한적입니다. 마크 업 규칙은 일반 브라우저를위한 자연스럽고 현대적인 방식과 다릅니다. 좋은 예는 전자 메일 클라이언트가 테이블에 친숙하다는 것입니다. 현대 웹에서는 요즘 테이블을 거의 사용하지 않습니다. 특히 화면을 교차하는 플랫폼 브라우저 인 경우 응답 성을 유지하려는 경우 더욱 그렇습니다. 여기에있는 모든 제한 사항에 대해 읽어보십시오. email-standards.org

HTML은 현대적인 웹 용으로 정교 할 필요가 없으므로 전자 메일 메시지 일 필요는 없습니다.

이러한 모든 이유는 인기있는 상업용 이메일 발신자의 온라인 아이디어입니다. 그들은 이메일 배포 목록을 작성하는 데 도움을주고 어깨에 적절한 제한된 HTML을 생성하기 위해 두통을 앓습니다. 그렇지 않으면 존재할 것입니까? 아무도 마크 업 차이가 아니라면 그룹 이메일을 보낼 수 있습니다.

내 결론이 : 전자 메일에 웹 페이지 마크 업을 사용하기로 결정한 경우 두 가지 모두를 제한하고 있습니다. 너는 공학 이상이야. 전자 메일 메시지에 일반 페이지 마크 업을 재사용하지 않으면 훨씬 간단 해집니다. 나는 그들이 오늘 비슷하다는 것을 이해하지만 내일이 아닐 수도 있습니다.

물론, 이메일 엔진에 템플릿 기능을 추가하는 것이 좋습니다 (웹 페이지 마크 업 재사용과 관련이 없음). 기존 템플릿 엔진을 사용할 수도 있고, 파일이나 데이터베이스에서로드 된 HTML 메시지 템플릿이 있으면 더러운 string.Replace()가 값으로 대체됩니다.

다른 말로하면 직접 질문에 대답하십시오. 웹 페이지와 이메일의 두 경로를 주저하지 마십시오. 대부분이 다른 기능이므로 공유하지 마십시오. 두 가지를 서로 고립시켜 생각해보십시오.