我目前正在开发一个高流量的在线搜索网站。
他们希望随着时间的推移实现各种更改，并且他们已经表明最终他们希望在ASP.NET MVC中重新完成该站点。
目前该站点是一个ASP.NET WebForms项目;但是很少使用真正的ASP.NET控件。相反，有许多服务器端标签 - 即＆lt;％...％＆gt;。这些标记中的代码通常是对静态类中的静态方法的调用，或者是生成HTML的C＃代码片段。
许多静态方法通过将文本附加到字符串构建器并将其作为字符串返回来生成HTML。
我理解'Helper'方法的概念，但我不喜欢通过将HTML连接到字符串变量来呈现HTML的想法。我认为他们最好不要使用'Partials'。
我担心的是它是一个非常复杂的网站，我不确定在ASP.NET MVC中完全重建网站是不是一个好主意。
尽管结构不好，但添加要求的新功能并不是那么难。 （也许是因为我有过使用困难代码的经验）。
但是我认为，除非我们对代码库进行彻底的清理，否则在将来的某个时候会出现一个很难实现的风险。
我想把这个问题放在那里，看看是否有人面临类似的问题，以及你是如何处理的。
另外，您对重建20％的边项目有什么看法？这样做是否有任何缺点？
答案 0 :(得分：1)
我个人认为，就UI而言，任何用ASP.Net编写的网站都需要完全重新完成。 MVC完全不同。
另一方面，你的业务逻辑应该没问题，尽管我认为只要你有关注的分离并且它不受UI的限制。
数据访问应该没问题，可能需要最少的触摸。但这又取决于您的网站的紧密程度。
我认为最好的方法是花一些时间来研究MVC如何开展业务，并对转换所需的内容进行批判性分析，然后开始转换UI上的所有层。
让你的基础到位，如果可能的话，甚至可以使用MVC框架。再次，只有你能够而且只有在可行的情况下。
作为一个副项目这样做我认为是因为你可以带一些你的库并开始转换它们以进行mvc转换。
但请注意，一旦你转换了一个项目/层，你（它）实现了它，否则它会冒被遗忘的风险，或者对另一层进行更改，然后需要将其编码为新的等等。知道陷阱。
至于UI，这将是最重要的，特别是如果你使用了很多asp控件。您可能希望花费大量时间来评估UI，并提出您需要替换或编写的控件列表。然后你就可以开始看到一种模式并获得一致性。
如果您的代码背后有很多代码，您可能希望开始将其移动到另一个层，因为这将在以后创建控制器等时提供帮助。然后他们可以实例化您的新图层，一切都应该是好的。
这就是我能从头脑中想到的一切。我会在想到事情的时候编辑或评论。
希望这有帮助。
答案 1 :(得分：0)
如果我有该项目并且我被要求从头开始重做，我将不会使用MVC来呈现UI，我将使用Web API / OData来托管所有后端，并将使用任何好的前端来绘制UI，Angular将是一个非常好的选择。
只有当旧项目中的更改和新功能的步伐小于新项目中的进度时，将其作为辅助项目才是好的，您不希望最终做出重复工作这一点，你将不得不冻结旧的代码。
此外，如果必须更改数据存储选项，则必须考虑任何数据迁移。