NopCommerce Platform introduce Part 1 and part2

Article I describes How to publish a nopCommerce application on windows 10

https://www.iaspnetcore.com/blogpost-63d054a54ccfe702c81ff3ec-nopcommerce-platform-introduce-part-1

https://www.iaspnetcore.com/blogpost-63d059074ccfe702c82088ae-nopcommerce-platform-introduce-part-3

Article I describes install nopcommerce first on window 10.

项目架构分层

系统架构分层和项目架构分层的区别？
这两个从字面意思很容易混淆，但是这两个概念的确是两码事，希望大家能否分的清楚。
• 系统架构分层：站的角度是硬件（物理）层面（反向代理，正向代理，第三方中间件）。
• 项目架构分层：站的角度是软件（逻辑）层面（Code代码层面）。

经典的三层架构(3-Layer)优缺点
• 优点：分层简单，容易上手，是code monkey猴子都容易上手。
• 缺点：大量重复性的CRUD代码。
阿笨经常说的一句话：erverything is price
一个新的东西的引入虽然解决了上一个存在的问题，但是也是有代价了，将会产生出新的问题。

顾名思义，三层架构分为三层，分别是“数据访问层”、“业务逻辑层”、“表示层”。
• 数据访问层(DAL)：实现对数据库中数据的读取和保存操作。
• 业务逻辑层(BLL)：它是DAL和UI层的连接桥梁.既然称作业务层,必然有他的用处,不仅仅是一个中转的功能。

阿笨给大家的建议要记住UI层面上的逻辑可以放在UI层，业务层面上的逻辑建议还是规范一点放在业务逻辑层。
业务逻辑层BLL到底有什么用?
https://www.cnblogs.com/Garden-blog/archive/2011/04/12/2013268.html
• 表示层(UI)：主要功能是显示数据和接受传输用户的数据，例如Windows窗体和Web页面。

三、Repository仓储模式优缺点
1）、什么是仓储(Repository)是什么？
Repository;中文翻译为仓库，大家都知道仓库里面装了很多各种各样的东西，那么你需要东西只要从仓库里面拿去就可以了，你不用关系仓库里面的东西存放在具体的那个位置上。调用方不要问，也不需要知道，你只负责从里面拿(获取)即可。
一般结合ORM框架，比如EF，Dapper等等。因为这类的框架天生就具备了高度复用的CRUD特性功能。
• 优点：
1、CRUD达到了复用目的（把一些公共的调用数据库的方法剥离出来，减少冗余的代码）。
2、为业务开发（程序开发）提供统一的规范。大家编码都规范了，都按照标准的作业模式让仓库中放存放(编写代码)自己的东西了，用到的时候大家都可以互相借用（共用）。
• 缺点：
1）、多个Repository之间怎么保存在一个事务单元内的操作？

三、UnitOfWork工作单元模式
1. 什么叫工作单元？

跨多个请求的业务，统一管理事务，统一提交。
2. 为什么要工作单元？

我们经常的代码都是分层的，有可能到处都在 new DbContext(options)，这是就要面对如何管理这些DbContext，在AspNetCore中 services.AddDbContext<>默认是用的Scope的作用域，也就是每次HttpRequest，比以前好了很多。但是事务这些管理还是很麻烦。

如上图有一个Action需要调用很多Service 然后 Service之间又相互调用，在开启Action时其实是想开启一个事务，但是某些内部代码有可能自己去开启了事务。相互之间调用管理起来非常麻烦。经常出现不可估计的问题。如果有一个集中管理的地方就好很多。比如在Action这里启动一个工作单元，后续所有的业务都使用同一个事务和 DbContext，这才是我们的预期的。

3. 如何使用工作单元？

http://www.aspnetboilerplate.com/Pages/Documents/Unit-Of-Work

只需要记住一点：当 Unit Of Work 中的 Commit() 方法执行时，所有仓库Repository中发生在对象上的修改都将提交到数据库中。

有一个Action需要调用很多Service 然后 Service之间又相互调用，在开启Action时其实是想开启一个事务，但是某些内部代码有可能自己去开启了事务。相互之间调用管理起来非常麻烦。经常出现不可估计的问题。如果有一个集中管理的地方就好很多。比如在Action这里启动一个工作单元，后续所有的业务都使用同一个事务和 DbContext，这才是我们的预期的。

专题系列目录

useful links

NopCommerce源码架构详解

https://www.byteflying.com/archives/1351