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