EF Core-1

带着问题去思考，你们好！

前几天了解到EF Core的开发模式：DB First（数据库优先）,Model First（模式优先），Code First（代码优先）。

我所接触的大可能是DB First。若是你们了解的话，有些开源后台项目，基本都会有后二者，由于方便你们更快的去使用部署起来后台。

在建议的Layered ['leɪəd] Architecture [ˈɑːrkɪtektʃər]模式中,---表示层，业务层和数据层，其后Evans分析并引入两个关键变化。

一：将关注点放到layer上，而不是tier。layer是应用程序组件之间的逻辑分隔,而tier是物理上不一样的应用程序和服务器。

二：识别的层数分为4各层-表示层-应用层-领域层和基础结构层

 

 

 

 

总体式应用程序

　　自底向下设计，咱们都是围绕着数据模型来进行开发设计，其中的过程以及尤为依赖数据模型的用户界面和体验。

　　 在总体式应用程序中，数据从底部的持久化存储到前端，而后在返回。

　　根据分层架构，咱们都知道，从存储到前端以及从前端到存储。咱们不该该考虑把应用程序堆栈分红两部分吗？独立处理命令堆栈和读堆栈对于开发是否是更加有效果呢？因此NOSql存储来了，使得经典的RDBMS系统开始支持XML和JSON。这也正式Command and Query Responsibility Segregation(CQRS)模式的使用。

 

 

 

 

 

以上是结合CQRS设计的分层架构模式

CQRS方法

CQRS不是万能的，重要的是他的思想。

　　有经验的开发人员知道。建立一个理想的数据模型，使其可以将关系数据模型的原则和最终用户实际须要的视图的复杂性结合起来是很困难的。若是只有一个应用程序堆栈，就只能有一个面向持久化的数据模型，可是须要调整这个模型，使其可以有效的知足前端的需求。特别是与某种方法学（如领域驱动设计的额外的抽象层结合起来时）,后端（业务逻辑和数据访问逻辑）的设计很容易变得一团乱。

　　以上问题。CORS经过将设计问题分解为两个较小的问题，新应用程序架构设计解决问题，并不释施加外部约束，使设计变得更加简单。具备不一样的堆栈的好处是，容易为实现名利和查询使用不一样的对象模型。有必要，能够为命令使用一个完整的领域模型，为表示使用一个定制的普通的数据传输对象，可能这些对象从SQL查询具体化的，须要多个表示前端，只须要额外建立读模型。总体复杂度是个体复杂度的和，而不是笛卡尔积。

　　1：不一样的数据库

　　分解成不一样的堆栈有一些问题,两个堆栈同步问题，数据命令写入可以被一致地读回？根据自身业务，CQRS实现能够基于一种两种数据库，若是使用一个共享数据库，共享数据库确保了经典的ACID一致性，只须要在读堆栈中的普通查询作一些额外的工做。

　　性能和扩展行，能够考虑为命令堆栈和读堆栈使用不一样的持久化端点。

　　

 

何时用CQRS？

这是一种模式，CQRS架构模式主要是被设计来解决高并发业务场景的性能问题。

基础结构层的构成

基础结构层是与使用具体的技术相关的全部东西，包括数据持久化O/RM框架（EF），外部的Web服务，特定的安全API，日志记录，跟踪，IOC容器，缓存等。最突出的是组件的持久化层，也就是数据访问层。

持久化层 缓存层 外部服务这些已经很是成熟，不在这里赘述。