Zのフロントからのスタートと分離の後部一端[.NET Core2.2 / 3.0 + Vue2.0]全体の倉庫を構築するためのフレームワークシックス・|| APIプロジェクト+ 6.1 +抽象サービス・インターフェース・モード

 

テキスト

記事のこの記事はバージョン3.0

この記事の内容は、また、変更なしでバージョン3.0に適用されます。

 

 

序文

 

  ブックは、テキストに接続:前の記事へ戻って、我々は枠組み文書闊歩のインタフェースの簡単な理解で3日間過ごし、完全に私たちの以前のWord文書を解放しており、オンラインデバッグすることができ、そしてときに、プロジェクトの開始我々はそれが、今日、もちろん、これはまだ私が言った、フロントの分離および後端からは程遠いので、欠陥を達成することは、フロントとリアエンドを待たない、まだ非常に良いですが、空のインターフェイス、または虚偽のデータを定義することができます我々は、単に私たちのプロジェクトのアーキテクチャを構築します。

  このプロジェクトは、以前MVC + EFコードファーストプロジェクトを設定していた、プロジェクトはこれに基づいて、データが真である、私自身の実際のプロジェクトである、と私はこのような、このシリーズでは、構築していたいくつかの時間前チュートリアルが再び開始します。

 

ゼロは、図のピンク色の部分が完了します

 

 

 

コール簡潔には、下の層の間の関係を説明します。

 

外部のプロジェクトに加えて、外部のAPIプレゼンテーション層、およびコア層のエンティティモデルの露出しています

 

ストレージモジュール(データベース管理者として、直接データベース操作、エンティティモデル):

BaseRepository(ストレージクラスイル)共通放電法IBaseRepository、継承インタフェースを実装し、
AdvertisementRepostitoryはBaseRepository <広告>、IAdvertisementRepositoryを継承しました

 

サービスモジュール(ビジネスロジックの処理は直接のViewModelビューモデルを使用することができます):

BaseService 调用 BaseRepository,同时继承 IBaseService
AdvertisementServices  继承   BaseServices<Advertisement>, IAdvertisementServices

 

 2019-08-30:关于仓储的相关话题

很多人都有一个这样的想法,仓储就是Dal层?我这里简单说一下两者的区别(我Blog.Core项目可能不是体现的出来,DDD可能更好理解):

1、仓储是一种模式,可以单建一层,也可以放到基础设施层,

      而Dal是三层架构种的某一层,是一个架构

2、仓储官方的定义,他是一个管理者,去管理实体对象和ORM映射对象的一个集合,是ORM操作db,

      而Dal就是完完全全的操作db数据库了,

      请注意,不要把 Sqlsugar 当成三层中的 sqlhelper,不一样!     

3、仓储更多的是一个聚合,在下一个系列DDD中,我们说到了一个概念,一个聚合的划分其实就是一个仓储。

4、然后我们进一步细化,一个仓储 = 一个聚合 = 有一个聚合根 = 一个微服务!

     多个微服务之间交互,就是通过聚合根来的。

 

 

 

一、创建实体Model数据层

  其中,Models文件夹中,存放的是整个项目的数据库表实体类,这里是手动创建的,当然也可以自动创建,在以后的文章中我会提到,用到的是SqlSugar的T4创建,这里先埋一个伏笔。

提示:这个伏笔已经完成,地址《 三十二║ 四种方法快速实现项目的半自动化搭建

  然后,VeiwModels文件夹,是存放的DTO实体类,在开发中,一般接口需要接收数据,返回数据,我之前都是这么红果果的使用的,后来发现弊端很大,不仅把重要信息暴露出去(比如手机号等),还对数据造成冗余(比如我需要接收用户的生日,还需要具体的年、月、日这就是三个字段,当然您也可以手动拆开,这只是一个栗子,所以不能直接用数据库实体类接收),就用到了DTO类的转换,但是频繁的转换又会麻烦,别慌,以后的文章中,我们会引用AutoMapper来自动转换,这里再买一个伏笔。

提示:这个伏笔已经完成,地址《十三 || DTOs 对象映射使用

  最后的是MessageModel和TableModel,大家也基本一看就能明白,因为在前端接口中,需要固定的格式,以及操作,不能把数据直接发出去,会报错,在以后的Vue开发中,会提到这个,这里又买了一个伏笔。 如下:

コードをコピー
 /// <summary>
    /// 通用返回信息类
    /// </summary>
    public class MessageModel<T>
    {
        /// <summary>
        /// 操作是否成功
        /// </summary>
        public bool Success { get; set; }
        /// <summary>
        /// 返回信息
        /// </summary>
        public string Msg { get; set; }
        /// <summary>
        /// 返回数据集合
        /// </summary>
        public List<T> Data { get; set; }

    }
コードをコピー

整个项目运行,没错,继续创建下一层。

 

二、设计仓储接口与其实现类

创建Blog.Core.IRepository和 Blog.Core.Repository 仓储层:

  这里简单说下仓储层:repository就是一个管理数据持久层的,它负责数据的CRUD(Create, Read, Update, Delete) service layer是业务逻辑层,它常常需要访问repository层。有网友这么说:Repository(仓储):协调领域和数据映射层,利用类似与集合的接口来访问领域对象。Repository 是一个独立的层,介于领域层与数据映射层(数据访问层)之间。它的存在让领域层感觉不到数据访问层的存在,它提供一个类似集合的接口提供给领域层进行领域对象的访问。Repository 是仓库管理员,领域层需要什么东西只需告诉仓库管理员,由仓库管理员把东西拿给它,并不需要知道东西实际放在哪。

 

   我们定义了IRepository层,提供了所有的操作接口,今天搭建框架,我简单地写一个实例,明天我们将把所有的方法嵌套进去。

  在 IAdvertisementRepository.cs 中,添加一个求和接口

  

   public interface IAdvertisementRepository
    {
        int Sum(int i, int j);
    }

  然后再在 AdvertisementRepository.cs 中去实现该接口,记得要添加引用,这个应该都会,就不细说了。  

コードをコピー
    public class AdvertisementRepository : IAdvertisementRepository
    {
        public int Sum(int i, int j)
        {
            return i + j;
        }
    }
コードをコピー

 

   运行项目,一起正常,继续往下。

三、设计服务接口与其实现类

创建 Blog.Core.IServices 和 Blog.Core.Services 业务逻辑层,就是和我们平时使用的三层架构中的BLL层很相似:

 

  Service层只负责将Repository仓储层的数据进行调用,至于如何是与数据库交互的,它不去管,这样就可以达到一定程度上的解耦,假如以后数据库要换,比如MySql,那Service层就完全不需要修改即可,至于真正意义的解耦,还是得靠依赖注入,这下一节我们会讲到。

  这里在 IAdvertisementServices 中添加接口

  

コードをコピー
namespace Blog.Core.IServices
{
    public interface IAdvertisementServices 
    {
        int Sum(int i, int j);
    }
}
コードをコピー

  然后再在 AdvertisementServices 中去实现该接口

コードをコピー
 public class AdvertisementServices : IAdvertisementServices
    {
        IAdvertisementRepository dal = new AdvertisementRepository();

    public int Sum(int i, int j) { return dal.Sum(i, j); } }
コードをコピー

  注意!这里是引入了三个命名空间

using Blog.Core.IRepository;
using Blog.Core.IServices; 

using Blog.Core.Repository;

 

四、创建 Controller 接口调用

 

 

   将系统默认的ValueController删除,手动添加一个BlogController控制器,可以选择一个空的,也可以选择一个带有默认读写实例的。如下:

  

コードをコピー
  [Produces("application/json")]
    [Route("api/Blog")]
    [Authorize(Policy ="Admin")]
    public class BlogController : Controller
    {
        // GET: api/Blog
        [HttpGet]
        public IEnumerable<string> Get()
        {
            return new string[] { "value1", "value2" };
        }

        // GET: api/Blog/5
        [HttpGet("{id}", Name = "Get")]
        public string Get(int id)
        {
            return "value";
        }
        
        // POST: api/Blog
        [HttpPost]
        public void Post([FromBody]string value)
        {
        }
        
        // PUT: api/Blog/5
        [HttpPut("{id}")]
        public void Put(int id, [FromBody]string value)
        {
        }
        
        // DELETE: api/ApiWithActions/5
        [HttpDelete("{id}")]
        public void Delete(int id)
        {
        }
    }
コードをコピー

  接下来,在应用层添加服务层的引用

using Blog.Core.IServices;
using Blog.Core.Services;

   然后,改写Get方法

コードをコピー
 ·······// GET: api/Blog
        /// <summary>
        /// Sum接口
        /// </summary>
        /// <param name="i">参数i</param>
        /// <param name="j">参数j</param>
        /// <returns></returns>
        [HttpGet]
        public int Get(int i,int j)
        {
            IAdvertisementServices advertisementServices = new AdvertisementServices();
            return advertisementServices.Sum(i,j);
        }
コードをコピー

  F5 运行项目,调试如下:

  天呀!出错辣!别慌,还记得昨天咱们加的权限么,嗯!就是那里,手动模拟登陆,获取Token,注入,不会的可以看上一篇,然后再执行,结果:

  

 

 

 

 

五、结语

  好啦,今天的工作暂时到这里了,你可以看到整体项目的搭建,结构,如何引用,如何测试等,当然,这里还是有很多小问题,比如:

  ·如果每个仓储都需要这么写,至少是四遍,会不会太麻烦;

  ·每次Controller接口调用,需要引入很多命名空间

  ·等等等等

  这些问题,下一节我们都会带大家一起去慢慢解决!

 

六、Github && Gitee

 
https://github.com/anjoy8/Blog.Core.git

https://gitee.com/laozhangIsPhi/Blog.Core

おすすめ

転載: www.cnblogs.com/qingshan/p/11906648.html