從壹開始先後端分離【 .NET Core2.0/3.0 +Vue2.0 】框架之二 || 後端項目搭建

時間 2019-11-05

標籤開始後端分離 core2.0 core 3.0 vue2.0 vue 框架之二項目搭建简体版

原文原文鏈接

本文3.0版本文章

https://mp.weixin.qq.com/s/U2-zxmYyRNTt97Dk5bA-2Anode

前言

至於爲何要搭建.Net Core 平臺，這個網上的解釋以及鋪天蓋地，想了想，仍是感受重要的一點，跨平臺，嗯！沒錯，並且比.Net 更容易搭建，速度也更快，全部的包均有Nuget提供，再也不像之前的單純引入組件，linux

已經沒有了以前的Assemblies和COM的引入，初次使用感受會很彆扭，不過使用多了，發現仍是很方便的，因此你必定要會使用Nuget，真的很強大，這點兒設計思路感受更像Linux了。nginx

下邊這三點，是先對 .net core 有一個初步的認識，看得懂或者看不懂都沒有關係，之後你們確定都會明白的：git

一、.net core 框架性能測試

http://www.techempower.com/benchmarks/ 咱們能夠經過這個web框架性能測試來看看 aspcore 的性能github

二、.net core 執行過程

三、中間件執行過程

啓動的時候先執行該中間件類的構造函數，而後一路 Next() ；下去，返回的時候，正好是反向的，執行的是該類的邏輯部分：web

四、AOP切面

五、總體框架結構與數據庫表UML

1、建立第一個Core

說了從零開始，就得從零開始，老生常談，開始。數據庫

一、SDK 安裝

固然，前提是你得安裝.Net Core，VS 2015也是能夠，只不過須要單獨安裝.Net Core,首先你得裝個vs2015 而且保證已經升級至 update3及以上。apache

個人 VS 是 2017，我這裏只說2017，有不會的網友能夠留言，只要在Visual Studio Installer 中安裝下圖中的Core 平臺便可。編程

下載 SDK 地址：https://dotnet.microsoft.com/downloadjson

選擇指定的平臺便可安裝：

這裏說下，SDK 和 RunTime 的區別：
1、SDK 是用來開發 NetCore 的，內部捆綁了 Runtime 運行時；
二、可是如何只想運行 NetCore 項目的話，只須要在服務器中安裝 Runtime 運行時便可；

怎麼判斷安裝成功了呢？直接運行命令，若是有結果證實成功了：

二、新建項目

一、File --> Project (記得文件名不要是中文，否則，你懂的)

二、而後選擇.Net Core 版本和項目類型，我選擇相對穩定的ASP.NET Core 2.2，而後選擇API的項目類型

至於其餘的，你們能夠本身玩一玩，還有就是是否Docker支持，這兩年Docker着實很火，我也會在之後的時間裏，補上這塊兒的使用。。。

Duang ，而後就出現了，特別簡單的一個.Net Core API就這麼誕生了，嗯不錯，基本的分紅這幾個部分，是否是特別像一個控制檯程序？並且真是簡潔了很多。

這裏要注意下，關於Https選項問題，有不少小夥伴在之後的接口調用中，勾選了這個，可是仍是一直使用 http 協議去訪問，致使找不到響應的接口地址。

一、是你的項目建立的時候，勾選了 Https 選項，若是你尚未建立，那就能夠不要勾選那個 HTTPS選項。

二、若是你的項目已經建立好了，每次訪問都是HTTPS的，可是你不想這麼作，能夠在 launthSettings.json 文件中，把sslPort 端口號改爲0便可

二、新建項目（3.0SDK）

點擊下一步。

而後建立模板：

三、項目總體結構分析

接下來我們看看這個項目都包含了哪些東西：

點開Controllers --> ValuesController 文件，你會發現四個方法，而且每一個方法也有各自的特性，分別是HttpGet,HttpPost,HttpPut,HttpDelete，這四個就是傳說中的RESTful風格的編程。

爲何會有這種風格呢：

RESTful 風格接口實際狀況是，咱們在先後端在約定接口的時候，能夠約定各類風格的接口，可是，RESTful 接口是目前來講比較流行的，而且在運用中比較方便和常見的接口。

雖然它有一些缺陷，目前 github 也在主推 GraphQL 這種新的接口風格，但目前國內來講仍是 RESTful 接口風格比較廣泛。而且，在掌握了 RESTful 接口風格以後，會深刻的理解這種接口的優缺點，到時候，你天然會去想解決方案，而且在項目中實行新的更好的理念，因此，我這系列的博文，依然採用 http://cnodejs.org/ 網站提供的 RESTful 接口來實戰。

瞭解程序開發的都應該知道，咱們所作的大多數操做都是對數據庫的四格操做「增刪改查」對應到咱們的接口操做分別是：post 插入新數據delete 刪除數據put 修改數據get 查詢數據

注意，這裏是咱們約定，並不是這些動做只能幹這件事情。從表層來講，除get外的其餘方法，沒有什麼區別，都是同樣的。從深層來講包括 get在內的全部方法都是如出一轍的，沒有任何區別。可是，咱們約定，每種動做對應不一樣的操做，這樣方便咱們統一規範咱們的全部操做。

假設，咱們的接口是 /api/v1/love 這樣的接口，採用 RESTful 接口風格對應操做是以下的：get 操做 /api/v1/love獲取 /api/v1/love 的分頁列表數據，獲得的主體，將是一個數組，咱們能夠用數據來遍歷循環列表post 操做 /api/v1/love咱們會往 /api/v1/love 插入一條新的數據，咱們插入的數據，將是JOSN利用對象傳輸的。get 操做 /api/v1/love/1咱們獲取到一個 ID 爲 1 的數據，數據通常爲一個對象，裏面包含了 1 的各項字段信息。put 操做 /api/v1/love/1咱們向接口提交了一個新的信息，來修改 ID 爲 1 的這條信息delete 操做 /api/v1/love/1咱們向接口請求，刪除 ID 爲 1 的這一條數據

由上述例子可知，咱們實現了5種操做，但只用了兩個接口地址， /api/v1/love 和 /api/v1/love/1 。因此，採用這種接口風格，能夠大幅的簡化咱們的接口設計。

提醒：2.1之後，新建的controller 所繼承的基類的 ControllerBase，致使在接口的返回值中，不能使用 return Json();方法，你可使用 return Ok(xxx)，效果是同樣的，

若是你必定要使用 Json，那就修改基類，繼承 Controller 吧。

而後 F5 運行，就會看到接口地址，以及對應的內容，你能夠根據本身的須要進行各類配置合適的路由，

這裏要注意下，若是出現特性相同，方法同名，參數同樣的，編譯會報錯，起名字很重要。

還有，這裏會自動跳轉到默認地址 api/values，固然是能夠配置的，就在 Properties --> launchSettings.json 中

接下來點開 appsettings.json 文件，這裏就是整個系統app的配置地址，更相似之前的web.config，之後你們會用到。

這裏還要說一下[HttpGet("{id}"),Name="Get"] ，這個有時候會帶 Name，不少小夥伴不知道這是幹啥的，我就簡單說一下：

[HttpGet("{id}", Name = "GetTodo")] public IActionResult GetById(long id)

"{id}" 是 todo 項的 ID 的佔位符變量。調用 GetById 時，它會將 URL 中「{id}」的值分配給方法的 id 參數。Name = "GetTodo" 建立一個命名的路由，使你可以 HTTP 響應中連接到此路由。稍後將使用示例進行解釋。有關詳細信息，請參閱路由到控制器操做，還有這個Attribute Routing in Web API 2

通常來講，路由名稱都是和路由url一一對應的，儘可能不要重複，不過也不多有人寫這個，沒啥用，因此通常不要寫。

繼續往下，打開Startup.cs 文件這裏是整個項目的啓動文件，全部的啓動相關的都會在這裏配置，好比依賴注入，跨域請求，Redis緩存等，更多詳情在之後的文章中都會有所提起

，

2018-09-23 更新

2、重要文件說明

一、Program.cs

namespace CoreBackend.Api
{
    public class Program
    {
        public static void Main(string[] args)
        {
            BuildWebHost(args).Run();
        }

        public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                .Build();
    }
}

這個Program是程序的入口, 看起來很眼熟, 是由於asp.net core application實際就是控制檯程序(console application).

它是一個調用asp.net core 相關庫的console application.

Main方法裏面的內容主要是用來配置和運行程序的.

由於咱們的web程序須要一個宿主, 因此 BuildWebHost這個方法就建立了一個WebHostBuilder. 並且咱們還須要Web Server.

asp.net core 自帶了兩種http servers, 一個是WebListener, 它只能用於windows系統, 另外一個是kestrel, 它是跨平臺的.

kestrel是默認的web server, 就是經過UseKestrel()這個方法來啓用的.

可是咱們開發的時候使用的是IIS Express, 調用UseIISIntegration()這個方法是啓用IIS Express, 它做爲Kestrel的Reverse Proxy server來用.

若是在windows服務器上部署的話, 就應該使用IIS做爲Kestrel的反向代理服務器來管理和代理請求.

若是在linux上的話, 可使用apache, nginx等等的做爲kestrel的proxy server.

固然也能夠單獨使用kestrel做爲web 服務器, 可是使用iis做爲reverse proxy仍是有不少有優勢的: 例如,IIS能夠過濾請求, 管理證書, 程序崩潰時自動重啓等.

UseStartup<Startup>(), 這句話表示在程序啓動的時候, 咱們會調用Startup這個類.

Build()完以後返回一個實現了IWebHost接口的實例(WebHostBuilder), 而後調用Run()就會運行Web程序, 而且阻止這個調用的線程, 直到程序關閉.

若是想要對AspNetCore源碼進行研究，能夠查看源碼，這裏提供兩個方法：

一、F12，固然這個不能看到詳細的，你須要安裝一個組件，VS2017 Resharper

二、查看Github 開源源碼 https://github.com/aspnet/MetaPackages/tree/master/src/Microsoft.AspNetCore

二、Startup.cs

namespace CoreBackend.Api
{
    public class Startup
    {
        // This method gets called by the runtime. Use this method to add services to the container.
        // For more information on how to configure your application, visit https://go.microsoft.com/fwlink/?LinkID=398940
        public void ConfigureServices(IServiceCollection services)
        {
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            //判斷是不是環境變量 if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            //這個就是一個簡單的中間件寫法
            app.Run(async (context) =>
            {
                await context.Response.WriteAsync("Hello World!");
            });
        }
    }
}

其實Startup算是程序真正的切入點.

ConfigureServices方法是用來把services(各類服務, 例如identity, ef, mvc等等包括第三方的, 或者本身寫的)加入(register)到container(asp.net core的容器)中去, 並配置這些services. 這個container是用來進行dependency injection的(依賴注入). 全部注入的services(此外還包括一些框架已經註冊好的services) 在之後寫代碼的時候, 均可以將它們注入(inject)進去. 例如上面的Configure方法的參數, app, env, loggerFactory都是注入進去的services.

Configure方法是asp.net core程序用來具體指定如何處理每一個http請求的, 例如咱們可讓這個程序知道我使用mvc來處理http請求, 那就調用app.UseMvc()這個方法就行. 可是目前, 全部的http請求都會致使返回"Hello World!".

看一看咱們項目的最後，Configure方法是如何配置的：

        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            if (env.IsDevelopment())
            {
                // 在開發環境中，使用異常頁面，這樣能夠暴露錯誤堆棧信息，因此不要放在生產環境。
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseExceptionHandler("/Error");
                // 在非開發環境中，使用HTTP嚴格安全傳輸(or HSTS) 對於保護web安全是很是重要的。
                // 強制實施 HTTPS 在 ASP.NET Core，配合 app.UseHttpsRedirection
                //app.UseHsts();

            }

            #region Swagger
            app.UseSwagger();
            app.UseSwaggerUI(c =>
            {
                //以前是寫死的
                //c.SwaggerEndpoint("/swagger/v1/swagger.json", "ApiHelp V1");
                //c.RoutePrefix = "";//路徑配置，設置爲空，表示直接在根域名（localhost:8001）訪問該文件,注意localhost:8001/swagger是訪問不到的，去launchSettings.json把launchUrl去掉

                //根據版本名稱倒序 遍歷展現
                typeof(ApiVersions).GetEnumNames().OrderByDescending(e => e).ToList().ForEach(version =>
                {
                    c.SwaggerEndpoint($"/swagger/{version}/swagger.json", $"{ApiName} {version}");
                });
            });
            #endregion

            #region Authen
            //app.UseMiddleware<JwtTokenAuth>();//注意此受權方法已經放棄，請使用下邊的官方驗證方法。可是若是你還想傳User的全局變量，仍是能夠繼續使用中間件
            app.UseAuthentication();
            #endregion

            #region CORS
            //跨域第二種方法，使用策略，詳細策略信息在ConfigureService中
            app.UseCors("LimitRequests");//將 CORS 中間件添加到 web 應用程序管線中, 以容許跨域請求。


            //跨域第一種版本，請要ConfigureService中配置服務 services.AddCors();
            //    app.UseCors(options => options.WithOrigins("http://localhost:8021").AllowAnyHeader()
            //.AllowAnyMethod()); 
            #endregion

            // 跳轉https
            app.UseHttpsRedirection();
            // 使用靜態文件
            app.UseStaticFiles();
            // 使用cookie
            app.UseCookiePolicy();
            // 返回錯誤碼
            app.UseStatusCodePages();//把錯誤碼返回前臺，好比是404

            app.UseMvc();
        }

三、調試方法

.net core 調試的兩種方法

一、經過IIS調試

二、項目自帶的Kestrel web應用調式

3、註冊並使用MVC

由於asp.net core 2.0使用了一個大而全的metapackage, 因此這些基本的services和middleware是不須要另外安裝的.

首先, 在ConfigureServices裏面向Container註冊MVC: services.AddMvc();

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddMvc(); // 註冊MVC到Container
        }

而後再Configure裏面告訴程序使用mvc中間件:

        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseMvc();

注意順序, 應該在處理異常的middleware後邊調用app.UseMvc(), 因此處理異常的middleware能夠在把request交給mvc之間就處理異常, 更重要的是它還能夠捕獲並處理返回MVC相關代碼執行中的異常.

而後別忘了把app.Run那部分代碼去掉. 而後改回到Develpment環境, 跑一下, 試試效果:

Chrome顯示了一個空白頁, 按F12, 顯示了404 Not Found錯誤.

這是由於我只添加了MVC middleware, 可是它啥也沒作, 也沒有找到任何可用於處理請求的代碼, 因此咱們要添加Controller來返回數據/資源等等

4、核心知識點

一、Routing 路由

路由有兩種方式: Convention-based (按約定), attribute-based(基於路由屬性配置的).

其中convention-based (基於約定的) 主要用於MVC (返回View或者Razor Page那種的).

Web api 推薦使用attribute-based.

這種基於屬性配置的路由能夠配置Controller或者Action級別, uri會根據Http method而後被匹配到一個controller裏具體的action上.

經常使用的Http Method有:

Get, 查詢, Attribute: HttpGet, 例如: '/api/product', '/api/product/1'
POST, 建立, HttpPost, '/api/product'
PUT 總體修改更新 HttpPut, '/api/product/1'
PATCH 部分更新, HttpPatch, '/api/product/1'
DELETE 刪除, HttpDelete, '/api/product/1

還有一個Route屬性(attribute)也能夠用於Controller層, 它能夠控制action級的URI前綴.

如下不是本系列，就看思路便可，不用敲代碼

//如下不是本系列教程，就看思路便可，不用敲代碼
namespace CoreBackend.Api.Controllers
{
    //[Route("api/product")]
    [Route("api/[controller]")]
    public class ProductController: Controller
    {
        [HttpGet]
        public JsonResult GetProducts()
        {
            return new JsonResult(new List<Product>
            {
                new Product
                {
                    Id = 1,
                    Name = "牛奶",
                    Price = 2.5f
                },
                new Product
                {
                    Id = 2,
                    Name = "麪包",
                    Price = 4.5f
                }
            });
        }
    }
}

使用[Route("api/[controller]")], 它使得整個Controller下面全部action的uri前綴變成了"/api/product", 其中[controller]表示XxxController.cs中的Xxx(實際上是小寫).

也能夠具體指定, [Route("api/product")], 這樣作的好處是, 若是ProductController重構之後更名了, 只要不改Route裏面的內容, 那麼請求的地址不會發生變化.

而後在GetProducts方法上面, 寫上HttpGet, 也能夠寫HttpGet(). 它裏面還能夠加參數,例如: HttpGet("all"), 那麼這個Action的請求的地址就變成了 "/api/product/All".

二、內容協商 Content Negotiation

若是 web api提供了多種內容格式, 那麼能夠經過Accept Header來選擇最好的內容返回格式: 例如:

application/json, application/xml等等

若是設定的格式在web api裏面沒有, 那麼web api就會使用默認的格式.

asp.net core 默認提供的是json格式, 也能夠配置xml等格式.

目前只考慮 Output formatter, 就是返回的內容格式.

若是想輸出xml格式，就配置這裏：

三、建立Post Action

如下不是本系列，就看思路便可，不用敲代碼

//如下不是本系列教程，就看思路便可，不用敲代碼　　　　 
[Route("{id}", Name = "GetProduct")]
        public IActionResult GetProduct(int id)
        {
            var product = ProductService...(x => x.Id == id);
            if (product == null)
            {
                return NotFound();
            }
            return Ok(product);
        }

        [HttpPost]
        public IActionResult Post([FromBody] ProductCreation product)
        {
            if (product == null)
            {
                return BadRequest();
            }
            var maxId = ProductService.Max(x => x.Id);
            var newProduct = new Product
            {
                Id = ++maxId,
                Name = product.Name,
                Price = product.Price
            };
            ProductService.Add(newProduct);

            return CreatedAtRoute("GetProduct", new { id = newProduct.Id }, newProduct);
        }

[HttpPost] 表示請求的謂詞是Post. 加上Controller的Route前綴, 那麼訪問這個Action的地址就應該是: 'api/product'

後邊也能夠跟着自定義的路由地址, 例如 [HttpPost("create")], 那麼這個Action的路由地址就應該是: 'api/product/create'.

[FromBody] , 請求的body裏面包含着方法須要的實體數據, 方法須要把這個數據Deserialize成ProductCreation, [FromBody]就是幹這些活的.

客戶端程序可能會發起一個Bad的Request, 致使數據不能被Deserialize, 這時候參數product就會變成null. 因此這是一個客戶端發生的錯誤, 程序爲讓客戶端知道是它引發了錯誤, 就應該返回一個Bad Request 400 (Bad Request表示客戶端引發的錯誤)的 Status Code.

傳遞進來的model類型是 ProductCreation, 而咱們最終操做的類型是Product, 因此須要進行一個Map操做, 目前仍是挨個屬性寫代碼進行Map吧, 之後會改爲Automapper.

返回 CreatedAtRoute: 對於POST, 建議的返回Status Code 是 201 (Created), 可使用CreatedAtRoute這個內置的Helper Method. 它能夠返回一個帶有地址Header的Response, 這個Location Header將會包含一個URI, 經過這個URI能夠找到咱們新建立的實體數據. 這裏就是指以前寫的GetProduct(int id)這個方法. 可是這個Action必須有一個路由的名字才能夠引用它, 因此在GetProduct方法上的Route這個attribute裏面加上Name="GetProduct", 而後在CreatedAtRoute方法第一個參數寫上這個名字就能夠了, 儘管進行了引用, 可是Post方法走完的時候並不會調用GetProduct方法. CreatedAtRoute第二個參數就是對應着GetProduct的參數列表, 使用匿名類便可, 最後一個參數是咱們剛剛建立的數據實體.

運行程序試驗一下, 注意須要在Headers裏面設置Content-Type: application/json.

四、Validation 驗證

針對上面的Post方法, 若是請求沒有Body, 參數product就會是null, 這個咱們已經判斷了; 若是body裏面的數據所包含的屬性在product中不存在, 那麼這個屬性就會被忽略.

可是若是body數據的屬性有問題, 好比說name沒有填寫, 或者name太長, 那麼在執行action方法的時候就會報錯, 這時候框架會自動拋出500異常, 表示是服務器的錯誤, 這是不對的. 這種錯誤是由客戶端引發的, 因此須要返回400 Bad Request錯誤.

驗證Model/實體, asp.net core 內置可使用 Data Annotations進行:

//如下不是本系列教程，就看思路便可，不用敲代碼
using System;
using System.ComponentModel.DataAnnotations;

namespace CoreBackend.Api.Dtos
{
    public class ProductCreation
    {
        [Display(Name = "產品名稱")]
        [Required(ErrorMessage = "{0}是必填項")]
        // [MinLength(2, ErrorMessage = "{0}的最小長度是{1}")]
        // [MaxLength(10, ErrorMessage = "{0}的長度不能夠超過{1}")]
　　　　 [StringLength(10, MinimumLength = 2, ErrorMessage = "{0}的長度應該不小於{2}, 不大於{1}")]
        public string Name { get; set; }

        [Display(Name = "價格")]
        [Range(0, Double.MaxValue, ErrorMessage = "{0}的值必須大於{1}")]
        public float Price { get; set; }
    }
}

這些Data Annotation (理解爲用於驗證的註解), 能夠在System.ComponentModel.DataAnnotation找到, 例如[Required]表示必填, [MinLength]表示最小長度, [StringLength]能夠同時驗證最小和最大長度, [Range]表示數值的範圍等等不少.

[Display(Name="xxx")]的用處是, 給屬性起一個比較友好的名字.

其餘的驗證註解都有一個屬性叫作 ErrorMessage (string), 表示若是驗證失敗, 就會把ErrorMessage的內容添加到錯誤結果裏面去. 這個ErrorMessage可使用參數, {0}表示Display的Name屬性, {1}表示當前註解的第一個變量, {2}表示當前註解的第二個變量.

在Controller裏面添加驗證邏輯:

//如下不是本系列教程，就看思路便可，不用敲代碼　　　　 
[HttpPost]
        public IActionResult Post([FromBody] ProductCreation product)
        {
            if (product == null)
            {
                return BadRequest();
            }

            if (!ModelState.IsValid)
            {
                return BadRequest(ModelState);
            }

            var maxId = ProductService.Max(x => x.Id);
            var newProduct = new Product
            {
                Id = ++maxId,
                Name = product.Name,
                Price = product.Price
            };
            ProductService.Add(newProduct);

            return CreatedAtRoute("GetProduct", new { id = newProduct.Id }, newProduct);
        }

ModelState: 是一個Dictionary, 它裏面是請求提交到Action的Name和Value的對們, 一個name對應着model的一個屬性, 它也包含了一個針對每一個提交的屬性的錯誤信息的集合.

每次請求進到Action的時候, 咱們在ProductCreationModel添加的那些註解的驗證, 就會被檢查. 只要其中有一個驗證沒經過, 那麼ModelState.IsValid屬性就是False. 能夠設置斷點查看ModelState裏面都有哪些東西.

若是有錯誤的話, 咱們能夠把ModelState看成 Bad Request的參數一塊兒返回到前臺.

五、PUT請求

put應該用於對model進行完整的更新.

首先最好仍是單獨爲Put寫一個Dto Model, 儘管屬性可能都是同樣的, 可是也建議這樣寫, 實在不想寫也能夠.

ProducModification.cs

    public class ProductModification
    {
        [Display(Name = "產品名稱")]
        [Required(ErrorMessage = "{0}是必填項")]
        [StringLength(10, MinimumLength = 2, ErrorMessage = "{0}的長度應該不小於{2}, 不大於{1}")]
        public string Name { get; set; }

        [Display(Name = "價格")]
        [Range(0, Double.MaxValue, ErrorMessage = "{0}的值必須大於{1}")]
        public float Price { get; set; }
    }

而後編寫Controller的方法:

//如下不是本系列教程，就看思路便可，不用敲代碼

[HttpPut("{id}")]
        public IActionResult Put(int id, [FromBody] ProductModification product)
        {
            if (product == null)
            {
                return BadRequest();
            }

            if (product.Name == "產品")
            {
                ModelState.AddModelError("Name", "產品的名稱不能夠是'產品'二字");
            }

            if (!ModelState.IsValid)
            {
                return BadRequest(ModelState);
            }

            var model = ProductService.SingleOrDefault(x => x.Id == id);
            if (model == null)
            {
                return NotFound();
            }
            model.Name = product.Name;
            model.Price = product.Price;

            // return Ok(model);
            return NoContent();
        }

按照Http Put的約定, 須要一個id這樣的參數, 用於查找現有的model.

因爲Put作的是完整的更新, 因此把ProducModification整個Model做爲參數.

進來以後, 進行了一套和POST如出一轍的驗證, 這地方確定能夠改進, 若是驗證邏輯比較複雜的話, 處處寫一樣驗證邏輯確定是很差的, 因此建議使用FluentValidation.

而後, 把ProductModification的屬性都映射查詢找到給Product, 這個之後用AutoMapper來映射.

返回: PUT建議返回NoContent(), 由於更新是客戶端發起的, 客戶端已經有了最新的值, 無須服務器再給它傳遞一次, 固然了, 若是有些值是在後臺更新的, 那麼也可使用Ok(xxx)而後把更新後的model做爲參數一塊兒傳到前臺.