我想知道什么是更好的方式。我创建了一个webapi项目，目前正在制作我的api。
将来我想要一个完整的asp.net mvc 4网站，它还可以包含将数据插入我的数据库的表格。
我不确定是否应该
A）
在我的web api项目中创建一个新区域，然后从那里构建我的网站。
b）中
将它保存在同一区域，只需在web api项目中创建一些新的控制器。
c）在我的web api解决方案项目中添加一个新的asp.net mvc 4项目。
答案 0 :(得分：4)
绝对是两个项目。事实上，我实际上建议三个项目：
您的MVC网站不应该查询您的Web API，而只是创建不必要的HTTP延迟。您的MVC站点和Web API都只是＆＃34;前端＆＃34;为您的类库。他们都会引用类库并与类库进行交互。
只有在您尝试提供第三方访问权限或者您正在使用其他语言与项目进行交互时，才需要使用Web API。如果一切都是.NET，那么只需共享DLL并将其称为一天。
答案 1 :(得分：2)
ķ。 Scott Allen最近撰写了一篇关于ASP.NET MVC和WebAPI共存的精彩文章，它涵盖了最常见的场景，以及何时适合将WebAPI与MVC一起使用，或者何时应该使用MVC。
我会使用它作为您的指南选择最能满足您当前需求的解决方案。我的建议是保持简单，如果您的要求很简单，那么没有理由不将WebAPI和MVC保留在同一个项目中 - 它运行得很好。随着您的要求发生变化，您可以随时将它们分成不同的项目或解决方案，但到那时您就会确切知道为什么要这样做。
答案 2 :(得分：0)
绝，
浏览链接http://efmvc.codeplex.com/
这是开发大型应用程序的最佳架构
这个可以帮助你...
另一个最好的MVC N-Tier架构MVC ---------＆gt; WEB API（服务）------＆gt; BL | DL（ORM）| DB）
你在同一个解决方案中创建它并构建应用程序......
答案 3 :(得分：0)
Web api和Web界面的单独项目将有助于拆分，但确实会导致重复。我们最近这样做了它运作良好，但它引起了一些问题。
拥有单个项目的论点：
由于我们还没有域名，我们在8080端口上有我们的API。我们可以使用目录绑定来从Web界面的子目录访问API，但我们担心生产只有关于绝对路径解析的错误。
两个项目之间共享许多设置，因此我们必须在两个web.config文件中复制它们。
拥有多个项目的论据：
它们更容易升级，因为它们可以具有不同的依赖关系，并且它们可以完全独立构建。例如，我们的API项目使用了一些最新版本的某些依赖项。
它强制您将所有业务逻辑提取到一个单独的库中，并且可以更容易地将这两个项目视为单独的子系统。
如果负载太大，将Web界面设置为单独的计算机会更容易。这对我们来说是一个问题，但可能不是你的情况。
如果我不得不再次作出这个决定，我可能不会打扰单独的项目，除非系统非常复杂，我需要额外的结构。可以对这两个选项进行争论，但我认为它带来的部署问题并不值得。