.NET ASP.MVC核心是否适合于快速的web开发？

Question

我目前在一家为企业和企业家开发网络应用程序的公司工作，通常每年有4-6个项目。我们目前使用的是Laravel/PHP，它允许我们以合理的可伸缩性、可维护性、安全性等方式相对快速地构建应用程序。

我不喜欢PHP作为一种语言，而且由于我对公司的方向有很大的影响，我已经向我的老板表明，我们最终应该在新项目上放弃PHP，采用更好的语言/框架(他已经同意了)。

我的建议是ASP.NET核心，我的老板对此没意见。我开始在平台上开发我们的最新项目，但在经历了一周的时间和几个阻碍开发的障碍之后，我决定回到PHP上，以确定最后期限。

我在.NET世界中遵循一个相当标准的分层体系结构(MVC、服务层、存储层)，这显然增加了时间，因为每个实体现在需要为每个层(和多个视图模型)提供几个组件，您可以将任意数据传递到视图并从请求中读取任意数据。我们不使用任何类型的服务/存储库层，而只是在控制器级别使用ORM，这是为了我们的目的而工作的。

我最初的想法是直接回拨分层体系结构(毕竟，我们甚至没有在PHP/Laravel上这样做)，但我担心的是，由于静态类型语言所需的冗长性，.NET Core根本不适合快速开发。看起来Ruby/Rails、Python/Django、JS/Node更适合快速原型化，而且在这种组合中，您不会经常听到(如果有的话) ASP。

.NET ASP.MVC核心适合于快速开发和原型开发吗？在.NET核心中构建不遵循分层方法的应用程序是否可行，还是会比上述语言/框架的应用程序更快变得难以管理？

Answer 1

是的，.Net内核虽然还很新，但适合于快速的web开发。

警告1: Asp.Net MVC/WebApi是比较成熟的技术。如果您正在执行较低级别的类型操作，您可能会发现它更兼容。

警告2:以你所知道的方式来说，你的编程速度总是更快。

在我看来，你在一个期限很紧的项目上做得太大了。

这显然增加了时间，因为每个实体现在都需要每个层的几个组件(以及多个视图模型)。

通常，每个视图只需要一个视图模型，编写它所需的时间最多为几分钟。

作为Laravel，您可以将任意数据传递给视图，并从请求中读取任意数据。

您可以这样在.net中编程，但是显然您失去了强大的类型优势，这将导致更快的开发和更少的but，一旦您习惯了它们。

我们不使用任何类型的服务/存储库层，而只是在控制器级别使用ORM，这是为了我们的目的而工作的。

同样，您可以在.net中直接访问控制器中的DB。这不是推荐的。

我想说的是，这并不是导致你慢下来的语言，而是试图同时加入大量的最佳实践。

强大的类型，层的分离，依赖注入，单元和集成测试确实使您的整体速度更快。

一旦习惯了，额外的输入并不是一个问题，但是只有在您早期发现but、适当的编译时间检查和单元测试时，才会真正显现出它的好处。

从一个较小、不太重要的项目开始，一步一步地走。