我应该在哪里将共享HTML生成代码放在ASP.NET MVC项目中？

Question

我有一个ASP.NET MVC解决方案，并且我有大量的ASP.NET MVC项目中的HtmlHelper类，它们会获取数据并生成各种html代码片段以在各种页面上显示。

我现在必须运行一堆计划作业，其中许多作业会生成电子邮件。我将所有这些工作都转移到了解决方案中的一个单独项目中（称为AdminJob.csproj），但是现在我发现必须生成一些电子邮件，其中包含非常类似于我在查看页面中的HTML的电子邮件。我试图保持管理工作不依赖于ASP.NET MVC项目（因为我想运行adminjob项目作为命令行，如果需要的话），我也想避免让我的ASP.NET MVC项目对AdminJob项目有依赖性（因为这看起来很奇怪）。

有关如何避免在ASP.NET MVC项目和我的AdminJob项目中重复相同的HTML呈现代码的任何建议？

我唯一能想到的是在名为“ViewHelpers”或类似的解决方案中创建另一个项目，并将我的所有HTMLHelpers移动到该项目中，以便它可以被我的MVC项目和AdminJob项目引用。对于这个代码有一个单独的项目似乎有些矫枉过正，但我​​想不出另一个不会产生重复的解决方案。

任何其他建议为更好的方式来做到这一点，并避免任何重复？

Answer 1

我看这里的方式是电子邮件是视图类型。在我的web应用程序（html，email，pdf，rss等）中有几种视图类型。这种模式有几种实现方式：ActionMailer在rails上的ruby或其到asp.net的端口：MvcMailer。

通过这种方式，您可以在Web应用程序和电子邮件中充分利用Razor引擎，以减少重复工作。

您可以在另一个项目中托管您的视图，并通知您的ViewEngine关于在哪里查看视图（请参阅Views in separate assemblies in ASP.NET MVC）。我觉得这是过分的。

另一种方式 - 我使用的是将电子邮件模板与其他视图放在同一个项目中。

如果你想呈现一个Web应用程序之外的意见，你可以使用其中之一编译控制台应用程序剃刀模板：

• 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?。

请注意，AdminJob对MVC项目具有编译时间依赖性，而不是可阻止AdminJob作为控制台应用程序运行。这可以正常工作。

我期望的问题 - 即使将View相关的东西移出到共享项目中，您可能会发现它在运行时在网站外部运行时会全部中断。在引擎盖下，有依赖于System.Web的东西，例如。 HttpContext，在运行时将为空。一些依赖关系可能被扼杀，有些不能。

在一个单独的共享项目中根本不能解决这个问题，所以我不认为移动代码可以获得任何收益。

但典型的方法（即5了近6年我公司工作过的的）这里是：

忘记命令行的想法。使管理工具成为网站的一部分。无论你认为你想从命令行运行，还是从管理工具上的按钮运行它。

PS

“的电子邮件非常相似HTML在我的视图页面”是一个结，你应该削减。

可以是或可以是与相同的视图页面，在这种情况下，您希望AdminJob重新使用视图页面;或者它不是。在这种情况下，AdminJob应该有自己的HTML。在第二种情况下，采取不存在“类似”HTML这样的东西的路线;如果不一样，那就不一样了。

Answer 3

我了解将常规网站页面中的html重用到您的电子邮件引擎中的诱惑。但是，我认为这是过度工程的一个好例子。这会比长期运行带来的好处造成更多的长期限制。

想想几件事情：

HTML的电子邮件是由设计不同于HTML页面进行。尽管今天他们看起来很相似，但明天他们看起来会不一样。你刚刚说过 - '电子邮件与我的查看页面中非常类似的HTML'，你没有说'用完全相同的HTML'。

电子邮件的HTML不应该有任何高级的HTML或任何JavaScript。理想情况下，它应该有内联CSS并且不支持JavaScript。与电子邮件客户端兼容的CSS非常有限。标记规则不同于为普通浏览器编写它的自然和现代的方式。很好的例子是电子邮件客户端对表格友好，而在现代网络中，你现在很少使用表格，特别是如果你想保持响应（跨屏幕平台浏览器）。阅读关于这里的所有限制：email-standards.org

现代网络的HTML不必像电子邮件消息那样是静态的。

这些所有的原因是流行的商业电子邮件发件人在线背后的想法。他们帮助您创建一个电子邮件分发列表，并且他们很头疼，在他们的肩膀上生成适当的有限的HTML。否则，他们会存在吗？如果不是标记差异，任何人都可以发送群组电子邮件。

我所有这一切的结论：如果你决定使用你的网页标记的电子邮件，你是限制两者。你是过度工程。如果您不在电子邮件中重复使用常规页面标记，这将会简单得多。我知道他们今天很相似，但他们可能不是明天。

显然，为您的电子邮件引擎提供模板功能是一个不错的主意（与重新使用网页标记无关）。为此，您可以使用任何现有的模板引擎，或者您可以快速编写您的代码（毕竟，如果将HTML消息模板作为字符串从文件或数据库加载，则dirty.Replace（）将用值替换占位符）。

换句话说，要直接回答你的问题：不要犹豫，分歧的两个网页和电子邮件的路径。避免共享功能，因为它们大多数不同。考虑两者彼此孤立。