小编use*_*696的帖子

看一下ASP.NET 5的源代码,我在HTTP抽象中发现了具体的实现IApplicationBuilder.该类有一个方法,负责从添加的中间件中构建管道.代码如下:

public RequestDelegate Build()
{
    RequestDelegate app = context =>
    {
        context.Response.StatusCode = 404;
        return Task.FromResult(0);
    };

    foreach (var component in _components.Reverse())
    {
        app = component(app);
    }

    return app;
}

我明白了:我们编写请求委托返回404的代码,这样如果没有中间件处理请求,我们就会返回404错误.现在,假设我们编写以下中间件(它只是一个Func<RequestDelegate, RequestDelegate>):

(next) => {
    RequestDelegate reqDelegate = new RequestDelegate(async context => {
        await context.Response.WriteAsync("Hello World!");
        await next.Invoke(context);
    });

    return reqDelegate;
} 

也就是说,它返回一个"Hello World"消息,并调用管道上添加的下一个功能,无论是什么.现在,如果我们只是通过Use调用添加Configure它,它将在我们请求任何内容时在屏幕上显示"Hello World".

但是等一下:404错误中间件正在添加到管道中,无论如何都是旁边的那个.在这种情况下,next.Invoke(context)应该只返回404.但它不会,也就是说,它显示状态代码为200的"Hello World".

我已经尝试编写另类中间件,并添加到管道中,两者都被调用,但404没有.我在这里缺少什么？为什么404没有被调用,因为他是管道的最后一个中间件的下一个？

编辑:做一些测试我发现了一些有趣的东西.我已经更改了这个hello world中间件,以便它只是在请求的路径上写入响应流/helloworld.在那种情况下,当我们请求时,http://localhost:5000/helloworld我们得到hello world消息并且不调用404中间件.

另一方面,如果我们请求任何其他路径, …

ASP.NET Core中有一点我认为我还没有完全理解,这就是请求功能的想法.正如文档中所解释的那样:

功能接口定义给定请求可能支持的特定HTTP功能.服务器定义功能集合以及该服务器支持的初始功能集,但中间件可用于增强这些功能.

我最初的理解是,请求功能是服务器应该公开的所有内容,以便在应用程序管道上使用.也就是说,服务器应该执行的行为,如发送文件.

另一方面,例如,存在认证请求特征.现在,我不确定身份验证属于这一类.它似乎不是应用程序应该调用的某些服务器行为,而是应用程序本身的一个问题.

这让我想知道什么才能真正成为一个请求功能.那么,什么使得某些东西成为ASP.NET Core中的请求功能？我最初的理解是错的吗？做出请求功能的决定背后是什么？

在新的.NET平台标准中,我们有netstandard TFM(Target Framework Moniker),它允许我们针对标准的一个特定版本.这样就可以在我们的代码中访问该版本上的可用API.

除了netstandard TFM,我们还有netstandardapp.我没理解.为什么我们需要这两个？如果我们想要以.NET平台标准为目标,我们是否只需要针对netstandard TFM？

在过去的几天里,我一直在尝试使用新的.NET CLI,虽然构建控制台和Web应用程序非常简单,但是如何构建类库并不是很明显.

我做了以下操作:像往常一样,在我用来dotnet new创建project.json文件的命令行上.然后我在这个项目中编写了一个简单的类,仅此而已.

然后我使用.NET CLI创建了一个控制台应用程序,其中包含第一个作为依赖项的应用程序,project.json并使用我在类库上构建的类来在屏幕上显示消息.

当我尝试运行控制台应用程序时,找到了另一个项目,.NET CLI尝试构建它.类库的构建失败,并显示以下消息:

程序不包含适用于入口点的静态"Main"方法.

在这种情况下,它将项目视为控制台应用程序并尝试查找主要入口点.

我相信这是因为当我使用dotnet new命令创建类库时,它生成project.json如下:

{
    "version": "1.0.0-*",
    "compilationOptions": {
    "emitEntryPoint": true
},
    "dependencies": {
        "Microsoft.NETCore.App": {
            "type": "platform",
            "version": "1.0.0-*"
        }
    },
    "frameworks": {
        "netcoreapp1.0": {}
    }    
}

在那里我相信可能有两个原因:其中一个原因是运行时是Microsoft.NETCore.App第二个TFM.

我尝试将TFM更改为netstandard1.5但它不起作用,给出了同样的错误.在那种情况下,我认为问题在于运行时.不知何故,我相信Microsoft.NETCore.App我们正在构建一个控制台应用程序,而不是一个库,然后需要一个入口点.

那么使用.NET Core CLI构建类库的正确方法如何呢？真的是运行时问题吗？如果是这样,我们如何处理它？

我对接口的理解是它们定义了契约，而实现该接口的类则对契约进行签名。在这种情况下，我们可以将类设计为依赖于合同而不是具体的实现。这具有减少耦合，启用多态性等优点。

现在，我遇到了一种我没有得到的接口。这是来自ASP.NET Core文档中有关配置的信息。特别是在该页面中，人们正在谈论使用ASP.NET Core设置MongoDB。

他们基本上定义了一个类和一个接口，如下所示：

namespace BooksApi.Models
{
    public class BookstoreDatabaseSettings : IBookstoreDatabaseSettings
    {
        public string BooksCollectionName { get; set; }
        public string ConnectionString { get; set; }
        public string DatabaseName { get; set; }
    }

    public interface IBookstoreDatabaseSettings
    {
        string BooksCollectionName { get; set; }
        string ConnectionString { get; set; }
        string DatabaseName { get; set; }
    }
}

然后他们按如下方式使用它：

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<BookstoreDatabaseSettings>(
        Configuration.GetSection(nameof(BookstoreDatabaseSettings)));

    services.AddSingleton<IBookstoreDatabaseSettings>(sp =>
        sp.GetRequiredService<IOptions<BookstoreDatabaseSettings>>().Value);

    services.AddMvc()
            .SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
}

我必须说我不明白。类型的对象应用BookstoreDatabaseSettings作设置的DTO。它们根本不提供任何功能。那么为什么要在中间引入一个接口呢？

我在这里看不到一种用法，可以在其他用法上使用。我在这里看不到为什么要尝试将其解耦，我根本看不到多态性的任何使用，而且我确实没有明白这一点。 …

阅读这个问题,@ Pinpoint的回答以及对评论的进一步讨论,我很清楚,我们原本无法在使用ASP.NET 5开发的应用程序中添加身份提供程序.然后,可以通过以下方式提供对旧版OAuthAuthorizationServerMiddleware的替代.我在许多地方找到的AspNet.Security.OpenIdConnect.Server.

现在,有一点我仍然不确定这一切因为我真的不是安全方面的专家,所以我对OAuth的了解不是很深刻.我怀疑如下:在使用OAuth保护一个RESTful API时是否可以使用外部身份提供程序？

请注意,我不是在谈论将社交登录添加到一个网站,我在谈论在一个RESTful API中使用一个外部身份提供程序.

我的观点是,这让我有点困惑,因为我一直认为这应该是我的应用程序的一个问题.

所以我的问题是:在使用OAuth和ASP.NET 5时,是否可以使用外部身份提供程序,而不是实现一个？如果有可能,这简单如何工作？我的意思是,我的应用程序仍然需要能够管理用户的身份,因为它需要管理声明等等.

在这种情况下,如果真的有可能,流程将如何？外部身份提供商应该发行令牌吗？但我的应用程序如何能够验证这些令牌并管理用户身份？

编辑:我不确定的原因之一是,当我们使用UseOAuthAuthentication扩展方法时,我们设置了一个回调路径,描述为

应用程序基本路径中将返回用户代理的请求路径.中间件将在到达时处理此请求.

现在,如果我们正在开发一个网站,那么这确实有意义.该人去那里,点击按钮登录Facebook等提供商.用户被重定向到Facebook的页面,然后在他登录后,他被重定向到该站点的某个页面.

另一方面,使用RESTful API,这是毫无意义的.没有被重定向的概念.

这使得外部提供程序的使用似乎仅适用于站点,而不适用于RESTful API.这是我的问题的要点.

今天,ASP.NET Core的RC1版本与DNX一起使用.据我所知,RC2的主要变化是ASP.NET Core将开始使用.NET Core CLI.

现在,这让人想到以下问题:如果DNX和.NET CLI只是工具,为什么这种迁移需要更改代码？

确实今天有人宣布需要Microsoft.AspNetCore.Mvc.Dnx来允许RC2中的Mvc与Dnx一起使用,我们看到使用带有DNX的ASP.NET Core MVC我们需要添加一个包以及更多,我们需要更改我们的代码,以便我们对调用ConfigureServices方法有所Startup了解services.AddMvcDnx();

这让我很困惑.我知道DNX和.NET Core CLI只是运行.NET Core应用程序的工具.如果这只是工具,为什么从一个迁移到另一个需要代码更改？

对于组织代码库的问题,打破大型解决方案通常是多个项目,这很容易在Visual Studio内部的早期版本的.NET Framework中完成.

如何使用.NET CLI完成相同的操作？假设我们有以下简化方案,例如:

- Solution Folder
    - global.json
    - src
        - LibProject
        - ConsoleProject

现在假设ConsoleProject取决于LibProject.直觉上我相信,这意味着,在ConsoleProject该project.json会必须包含一个dependencies这样的部分:

"dependencies": {
    "Microsoft.NETCore.App": {
        "type": "platform",
        "version": "1.0.0-*"
    },
    "LibProject": "1.0.0-*"
}

但是如果我们这样做,当我们尝试恢复依赖关系时,ConsoleProject或者当我们尝试构建它时,我们无法做到.当我们尝试恢复时,我们得到了消息

无法为'.NETCoreApp,Version = v1.0'解析'LibProject(> = 1.0.0)'.

我理解原因.在恢复时,NuGet正在尝试将其作为包上指定的Feed NuGet.config.但它不应该这样做,它应该使用兄弟文件夹中的那个.

在以前版本的.NET Core中,我们将通过VS添加引用,然后,如果我们尝试构建它ConsoleProject,VS将首先构建LibProject并使用相应的DLL.

怎么在这里做同样的事情？我们如何在同一解决方案中引用另一个项目？考虑到这种依赖性,我们如何使用.NET CLI恢复/构建/运行？

我一直在阅读有关事件采购的内容,虽然我发现这是一个很自然的方法来解决几个问题,但我并不太了解如何将事件存储在实践中.

在互联网上搜索一下我发现Vaughn Vernon 撰写的这篇文章谈到了在DDD中存储聚合的简单方法.虽然它不是专门针对事件来源,但他提出了一种使用PostgreSQL 存储域事件的方法.

在他的做法,我们有一个表Events有一个id和JSON data领域.这给了很多自由,因为我们可以存储任何JSON数据,因此我们可以存储各种事件.

但是让所有事件都对应于单个表中的所有聚合,让我有点担心.

因此,当我们存储事件以使用事件采购时,我们应该如何进行？我可以看到三个选项:

1. 遵循文章中用于域事件的想法,并将所有内容存储在单个表中.

2. 每个事件创建一个表.这里的缺点是我们需要跟踪每个聚合的事件,并且对于每个聚合,可以有各种类型的事件.所以这很容易导致一个巨大的表号.

3. 为每个聚合创建一个表,并在那里存储该聚合的所有事件.虽然我们最终在同一个表中汇总了不同类型的事件,但它们都与相同的聚合相关.

这三个选项中哪一个更合理？如果没有,那么在使用事件采购时存储事件的正确方法是什么？

我发现 Angular 2 组件非常好，因为我们可以写下适合我们正在构建的应用程序的自己的 HTML 元素，但是，由于我开始使用 Angular 2，我觉得我使用它们的方式是错误的.

我一直在使用组件的方式，而且我似乎其他人也在这样做，是在组件和视图之间建立 1-1 的对应关系。

换句话说，对于应用程序的每个视图，只创建一个组件并使用路由器来触发活动组件。

所以在这种情况下，会有这样的组件：

• 仪表板组件 - 它是仪表板视图
• 用户配置文件组件 - 它是用户配置文件视图
• 销售清单组件 - 它是销售清单视图
• 销售编辑器组件 - 它是销售编辑器视图，用于添加新销售或更新销售

等等。我的意思是，这行得通，但我觉得这是使用组件的错误方式。在我看来，不知何故组件应该比这更细粒度。

应该如何正确决定什么必须是 Angular 2 中的组件？真的应该在组件或视图之间进行这种 1-1 映射吗？如果不是，那么决定我们需要构建哪些组件的正确方法是什么？