我在Asp.net核心架构开发中的一些问题

Some issues in my mind in Asp.net core architecture development

我使用 Asp.net 核心 2.1 开始了一个项目,并阅读了几篇关于该主题的文章。

Asp.Net核心在新的架构,以及以前的,同时使用Razor页面,如Asp.Net还允许你在页面后面写代码。

1- 我觉得给项目注入依赖最好的地方就是controller classes。我真的不明白在新架构中将代码写到页面后面是什么感觉。此外,如果我们着眼于优化使用,我们应该在页面后面添加重新依赖。什么是逻辑

2- 我在做项目的时候发现Microsoft.AspNet.Identity.EntityFramework.IdentityDbContextMicrosoft.AspNet.Identity.EntityFramework.IdentityDbContextclass 和 Microsoft.AspNetCore.Identity.EntityFrameworkCore.IdentityDbContext classes。如果我们要升级任何旧的 Asp.Net 项目,是否有任何与架构要求相关的文档以及原因和最佳实践(如上述 DI 的情况)

I don't have a problem with building the project, I'm just writing here to document this topic in order to better understand it and not to waste unnecessary effort.

请右键单击“区域”>“添加新脚手架”项目我想如果您使用的是 VS 2017 pro+,您可能会得到一个可以添加的预定义 RazorPages 列表,我可以说它们主要与登录等身份操作相关,注册,更改密码,...您可以在您的应用程序中以最少的努力获得它们。

对于我的情况,如果我不打算实施复杂的身份模型,或者如果我不想为我的应用程序成员提供 asp.net 身份之外的其他东西,那么 Razor Pages 是最快的方式通常,RazorPages 与 Mvc ViewComponents 进行比较(我个人不喜欢在应用程序范围内频繁使用它)(我认为 razor 页面正在使用 MVVM 模式)

长话短说,我相信剃刀页面是在项目中做一些小功能甚至做小项目的最快和更有条理的方式,但想象一下你在一个大项目中有太多的动作,那么你将有大量难以维护的剃刀页面。

我可以推荐使用 mvc 方法并根据需要使用 razor 页面,对于这两种情况,您仍然可以将 class/interface 注入控制器构造函数或 Razor 页面构造函数并且仍然使用内置 asp.net 核心 DI (services.AddScoped, services.AddTransient, services.AddSingleton)

这里是Razor pages的源代码,有兴趣的可以看看;) https://github.com/aspnet/Mvc/tree/master/src/Microsoft.AspNetCore.Mvc.RazorPages