如何使用ABP進行軟件開發之基礎概覽

ABP框架簡述

1)簡介

在.NET眾多的技術框架中,ABP框架(本系列中指aspnetboilerplate項目)以其獨特的魅力吸引了一群優秀開發者廣泛的使用。

在該框架的賦能之下,開發者可根據需求通過官方網站【https://aspnetboilerplate.com/Templates】選擇下載例如Vue/AngluarJS/MVC等不同類型的模板項目,輕鬆加入ABP開發者的隊伍中,盡享基於ABP開發帶來的樂趣。

ABP開發框架也提供了豐富的文檔,能夠為開發者帶來許多便捷。目前ABP的文檔網站為:

官方文檔:https://aspnetboilerplate.com/Pages/Documents

文檔庫不可謂不全,加上國內眾多的ABP開發者參与的活躍的技術圈子,使得學習成本只是在第一個項目中比較高,後期將會越來越平滑。

2)現狀

當然,目前ABP的框架開發者和社區已經把更多的精力投入到了ABP.VNEXT開發框架,這個新框架以其DDD+微服務+模塊化的理念獲得了大量擁躉,使ABP框架的開發優先級已經開始逐漸降低。

但這是因為ABP框架的功能已經成熟穩定,且ABP是一種增量式的架構設計,開發者在熟練掌握這種框架后,可以根據自己的需要進行方便的擴展,使其成為小項目架構選型中一種不錯的備選方案。

當然,也存在一些弊端。例如由於ABP被稱為.NET眾多開發框架中面向領域驅動設計的最佳實踐,而囿於領域驅動設計本身不低的門檻,使得學習的過程變得看起來非常陡峭;

除此之外,ABP也廣泛使用了目前Asp.NET/Asp.NET Core框架的大量比較新的特性,對於不少無法由於各種原因無法享受.NET技術飛速發展紅利的傳統開發者來說,無形中也提高了技術門檻。

3)綜述

在這個系列中,本文計劃分成三篇來介紹ABP框架,第一篇介紹ABP的基礎概覽,介紹基礎知識,第二篇介紹ABP的模式實踐,第三篇,試圖介紹如何從更傳統的三層甚至是單層+SQL的單層架構,如何遷移到ABP框架。

(畢竟。。.NET遺留應用實在是太多了,拯救或不拯救?)

代碼結構結構

基本文件夾簡述

當我們通過ABP模板項目的官方網站下載一個項目后,我們所獲得的代碼包的結構如下圖所示,其中:

  • vue為使用iview框架構建的管理系統基本模板,該腳手架使用了yarn作為包管理器,並集成了vuex/axios等常用框架,並提供了用戶,租戶,權限三個基本功能的示例代碼,開發者只需發揮聰明才智就能快速的通過該框架入手前端項目。
  • (當然,該項目廣泛使用了typescript+面向對象的設計,似乎前端開發者。。普遍不擅長面向對象開發?)
  • aspnet-core則是一個完整的asp.netcore項目的快速開發腳手架。該腳手架集成了docker打包於一體,並包含基本的單元測試示例,使用了identity作為權限控制單元,使用swagger作為接口文檔管理工具,集成了efcore、jwt等常用組件,對於開發者來說,基本上算是開箱即用了。

前端vue項目

打開vue文件夾之後,該項目的基本目錄如下圖所示。(src文件夾)

lib文件夾

定義了與abp+vue腳手架項目的基礎組件和常見類庫,封裝了一系列基本方法。例如權限控制,數據請求,菜單操作,SignalR等基礎組件的用法。

router文件夾

定義了vue項目的路由規則,其中index.ts文件是項目的入口,router.ts文件定義了vue文件的路由規則。

store文件夾

由於本項目使用了vuex框架,所以我們可以來看看對於store文件夾的介紹。

在vuex框架中:

每一個 Vuex 應用的核心就是 store(倉庫)。“store”基本上就是一個容器,它包含着你的應用中大部分的狀態 (state)。
Vuex 和單純的全局對象有以下兩點不同:
Vuex 的狀態存儲是響應式的。當 Vue 組件從 store 中讀取狀態的時候,若 store 中的狀態發生變化,那麼相應的組件也會相應地得到高效更新。
你不能直接改變 store 中的狀態。改變 store 中的狀態的唯一途徑就是顯式地提交 (commit) mutation。這樣使得我們可以方便地跟蹤每一個狀態的變化,從而讓我們能夠實現一些工具幫助我們更好地了解我們的應用。

即vuex框架中,將原來的請求鏈路,抽象化為狀態的變化,通過維護狀態,使得數據的管理更加便捷,也易於擴展。

views文件夾

定義了登錄、首頁、用戶、角色、租戶的基本頁面,並提供了新增、查看、編輯、刪除的代碼示例。

綜上,該項目是一個結構清晰,邏輯縝密的前端框架,可以作為常見管理系統的腳手架。

後端項目

簡介

後端項目是一個遵循了領域驅動設計的分層,同時又符合Robert Martin在《代碼整潔之道》提出的【整潔架構】。

領域驅動設計簡介

在領域驅動設計的分層設計中,共有四個功能分層,分別是:

表示層(Presentation Layer):為用戶提供接口,使用應用層實現用戶交互。

應用層(Application Layer):介於用戶層和領域層之間,協調用戶對象,完成對應的任務。

領域層(Domain Layer):包含業務對象和規則,是應用程序的心臟。

基礎設施層(Infrastructure Layer):提供高層級的通用技術功能,主要使用第三方庫完成。

在後文中,基於abp對領域驅動設計的功能分層將進行多次、詳細敘述,本小節不再贅述。

整潔架構簡介

整潔架構是由Bob大叔提出的一種架構模型,來源於《整潔架構》這本書,顧名思義,其目的並不是為了介紹這一種優秀的架構本身,而是介紹如何設計一種整潔的架構,使得代碼結構易於維護。

(整潔架構就是這樣一個洋蔥,所以也有人稱它為“洋蔥”架構)

  1. 依賴規則(Dependency Rule)

用一組同心圓來表示軟件的不同領域。一般來說,越深入代表你的軟件層次越高。外圓是戰術是實現機制(mechanisms),內圓的是核心原則(policy)。

Policy means the application logic.

Mechanism means the domain primitives.

使此體系架構能夠工作的關鍵是依賴規則。這條規則規定軟件模塊只能向內依賴,而裏面的部分對外面的模塊一無所知,也就是內部不依賴外部,而外部依賴內部。同樣,在外面圈中使用的數據格式不應被內圈中使用,特別是如果這些數據格式是由外面一圈的框架生成的。我們不希望任何外圓的東西會影響內圈層

  1. 實體 (Entities)

實體封裝的是整個企業範圍內的業務核心原則(policy),一個實體能是一個帶有方法的對象,或者是一系列數據結構和函數,只要這個實體能夠被不同的應用程序使用即可。

如果你沒有編寫企業軟件,只是編寫簡單的應用程序,這些實體就是應用的業務對象,它們封裝着最普通的高級別業務規則,你不能希望這些實體對象被一個頁面的分頁導航功能改變,也不能被安全機制改變,操作實現層面的任何改變不能影響實體層,只有業務需求改變了才可以改變實體

  1. 用例 (Use case)

在這個層的軟件包含只和應用相關的業務規則,它封裝和實現系統的所有用例,這些用例會混合各種來自實體的各種數據流程,並且指導這些實體使用企業規則來完成用例的功能目標。

我們並不期望改變這層會影響實體層. 我們也不期望這層被更外部如數據庫 UI或普通框架影響,而這也正是我們分離出這一層來的原因所在。

然而,應用層面的操作改變將會影響到這個用例層,如果需求中用例發生改變,這個層的代碼就會隨之發生改變。所以可以看到,這一層是和應用本身緊密相關的

  1. 接口適配器 (Interface Adapters)

這一層的軟件基本都是一些適配器,主要用於將用例和實體中的數據轉換為外部系統如數據庫或Web使用的數據,在這個層次,可以包含一些GUI的MVC架構,表現視圖 控制器都屬於這個層,模型Model是從控制器傳遞到用例或從用例傳遞到視圖的數據結構。

通常在這個層數據被轉換,從用例和實體使用的數據格式轉換到持久層框架使用的數據,主要是為了存儲到數據庫中,這個圈層的代碼是一點和數據庫沒有任何關係,如果數據庫是一個SQL數據庫, 這個層限制使用SQL語句以及任何和數據庫打交道的事情。

  1. 框架和驅動器

最外面一圈通常是由一些框架和工具組成,如數據庫Database, Web框架等. 通常你不必在這個層不必寫太多代碼,而是寫些膠水性質的代碼與內層進行粘結通訊。

這個層是細節所在,Web技術是細節,數據庫是細節,我們將這些實現細節放在外面以免它們對我們的業務規則造成影響傷害

ABP的分層實現

在ABP項目中,層次劃分如下。

1. 應用層(Application項目)

在領域驅動設計的分層式架構中,應用層作為應用系統的北向網關,對外提供業務外觀的功能。在Abp模板項目中,Application項目也是編寫主要用例代碼的位置,開發者們在此定義與界面有關的數據行為,實現面向接口的開發實踐。

應用服務層包含應用服務,數據傳輸單元,工作單元等對象。

  • Application Service

為面向用戶界面層實現業務邏輯代碼。例如需要為某些界面對象組裝模型,通常會定義ApplicationService,並通過DTO對象,實現與界面表現層的數據交換。

  • Data Transfer Object (DTO)

最常見的數據結構為DTO(數據傳輸對象),這是來源於馬丁弗勒在《企業架構應用模式》中提到的名詞,其主要作用為:

是一種設計模式之間傳輸數據的軟件應用系統。 數據傳輸目標往往是數據訪問對象從數據庫中檢索數據。

在ABP的設計中,有兩種不同類型的DTO,分別是用於新增、修改、刪除的Input DTO,和用於查詢的Output DTO。

  • Unit of Work:

工作單元。工作單元與事務類似,封裝了一系列原子級的數據庫操作。

2. 核心層(Core項目)

核心層包含領域實體、值對象、聚合根,以及領域上下文實現。

  • Entity(實體):

實體有別於傳統意義上大家所理解的與數據庫字段一一匹配的實體模型,在領域驅動設計中,雖然實體同樣可能持久化到數據庫,但實體包含屬性和行為兩種不同的抽象。

例如,如果有一個實體為User,其中有一個屬性為Phone,數據為086-132xxxxxxxx,我們有時需要判斷該手機號碼的國際代號,可能會添加一個新的判定 GetNationCode(),可以通過從Phone字段中取出086來實現,這就是一種通俗意義上的行為。

  • Value Object(值對象):

值對象無需持久化到數據庫,往往是從其他實體或聚合中“剝離”出來的與某些聚合具備邏輯相關性或語義相關性的對象,有時值對象甚至只有個別屬性。

例如,上述實體,包含Phone字段,我們可以將整個Phone“剝離”為一個Telephone對象,該對象可包含PhoneNumber和NationCode字段。

public class User
{
     public Telephone Phone{public get;private set;}
}
public class Telephone
{
    public string  PhoneNumber {get;set;}
     public string NationCode  {get;set;}
}
  • Aggregate & Aggregate Root(聚合,聚合根):

聚合是業務的最小工作單元,有時,一個實體就是一個小聚合,而為聚合對外提供訪問機制的對象,就是聚合根。

在領域驅動設計中,識別聚合也是一件非常重要的工作,有一組系統的方法論可以為我們提供參考。

當然,事實上識別領域對象,包括且不限定於識別聚合、值對象、實體識別該對象的行為或(方法)本身是一件需要經驗完成的工作,有時需要UML建模方法的廣泛參与。

有時,我們會習慣於通過屬性賦值完成梭代碼的過程,從而造成領域行為流失在業務邏輯層的問題,那麼或許可以採取這樣的方法:

1、對象的創建,使用構造函數賦值,或工廠方法創建。

2、將所有對於屬性的訪問級別都設置為

public string Phone{public get;private set;}

然後再通過一個綁定手機號碼的方法,來給這個對象設置手機號碼。

public string BindPhone(string phone)
{
}

將所有一切涉及到對Phone的操作,都只能通過規定的方法來賦值,這樣可以實現我們開發過程中,無意識的通過屬性賦值,可能導致的“領域行為”丟失的現象發生。
這種方式可以使得對對象某些屬性的操作,只能通過唯一的入口完成,符合單一職責原則的合理運用,如果要擴展方法,可以使用開閉原則來解決。

但是,採用這種方式,得盡量避免出現:SetPhone(string phone) 這樣的方法出現,畢竟這樣的方法,其實和直接的屬性賦值,沒有任何區別。

  • Repository(倉儲)

倉儲封裝了一系列對象數據庫操作的方法,完成對象從數據庫到對象的轉換過程。在領域驅動設計中,一個倉儲往往會負責一個聚合對象從數據庫到創建的全過程。

  • Domain Service(領域服務)

領域服務就是“實幹家”,那些不適合在領域對象中出現,又不屬於對象數據庫操作的方法,又與領域對象息息相關的方法,都可以放到領域服務中實現。

  • Specification(規格定義)

規範模式是一種特殊的軟件設計模式,通過使用布爾邏輯將業務規則鏈接在一起,可以重新組合業務規則。

實際上,它主要用於為實體或其他業務對象定義可重用的過濾器。

3. 其他基礎設施(EntityFrameworkCore,Web.Core,Web.Host項目)

EntityFrameworkCore負責定義數據庫上下文和對EFCore操作的一系列規則、例如種子數據的初始化等。

Web.Core:定義了應用程序的外觀和接口。雖然從表面上看,Web.Core定義了作為Web訪問入口的控制器方法和登錄驗證的邏輯,看起來像是用戶表現層的東西,但是仔細想想,這些東西,何嘗不是一種基礎設施?

Web.Host:定義WEB應用程序的入口。

總結

本文簡述了ABP框架的前後端項目的分層結構,通過了解這些結構,將有助於我們在後續的實戰中更快入手,為應用開發插上翅膀。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

新北清潔公司,居家、辦公、裝潢細清專業服務

三次握手四次揮手

一直都知道 TCP 建立連接時需要三次握手,釋放連接時需要四次揮手,也大概能說出整個過程,但是一直對其中的設計思想理解不深,停留在“只可意會,不可言傳”的階段。這次寫一篇博客嘗試將其中的思想表達出來。

 

 

 

TCP 建連三次握手

首先解釋一下每個步驟的作用:
1、a 時刻,A 準備就緒,發送 SYN 包給 B,嘗試建立連接
2、b 時刻,B 收到 A 發來的 SYN 包,知道 A 要請求建連,回 SYN ACK 包,告訴 A 自己收到了建連請求,可以建連了
3、c 時刻,A 收到了 B 的回復,知道 B 準備好了,鏈路通暢,可以發送數據了。回  ACK 告知 B 收到了 B 的回復,下面要開始發送該數據了
4、d 時刻,B 收到了 A 的回復,知道 A 接下來要發數據了。至此,AB 雙方都確認整個鏈路已經可靠了,接下來可以發送數據了。

 

為什麼要多次確認呢?為什麼不可以 A 上來就直接發送數據給 B 呢?
這裏首先要明確一點,TCP 是傳輸層的協議,是建立在物理層、數據鏈路層、網絡層之上的協議,而底層的網絡是不可靠的,可能路由出問題,可能網關出問題,可能網線出問題,A 沒法保證自己發出來的消息 B 一定能收到,所以一定要反饋機制,即 ACK,這樣才能在不可靠的網絡層智商構建可靠的傳輸層。

 

類比一下生活中的例子,可以幫助我們理解
示例1,假設我們在火車上打電話,通話質量很差,我們的通話過程可能會是下面這樣:

 

 

AB 雙方首先需要確認彼此都能挺到對方的聲音,也就是保證電話通道是可靠的,之後才會開始說正事。如果一上來就直接說正事,可能 A 說完之後 B 根本就沒有聽到。
實際打電話過程中,如果遇到了斷線的情況,雙方可能需要進行多次“握手”確認。

 

示例2,假設我們給剛認識的人第一次打電話,通話過程可能是下面這樣:

 

 

AB 雙方都要確認對方的身份,也就是保證通話是在跟自己人進行,確保電話通道是可靠的,不是跟騙子通話,然後才會開始說正事。如果一上來沒有確認身份,不能保證通道是跟自己人進行的,那直接說出重要的事,很可能就泄漏了機密。

 

總之,握手過程的最終目的就是保證雙方都準備就緒,通路是可靠的,之後就可以放心的發送重要數據了。

 

那為什麼一定是三次呢,為什麼不是兩次或者四次呢?
先來說一下為什麼不能少。
一次可以嗎?不可以。設想一下,A 對 B 說:我要給你發數據。然後不等 B 的回復,接下來就開始發數據了。這時候根本不能保證 B 已經準備好了,那 A 發出來的數據就沒法保證 B 一定能收到。聯想生活中的場景,你隔着很遠的距離向對方喊話:我要把蘋果扔給你。然後不關心對方有沒有聽到,就直接扔了,那最終的結果通常就是對方接不到蘋果,因為對方可能根本沒有收到消息。
兩次可以嗎?不可以。設想一下,A 對 B 說:我要給你發數據,然後 B 收到消息后給 A 回復:收到,A 在收到 B 的回復后開始發送數據。這時候 A 端是可以準備就緒的,但是 B 端不知道 A 端當前的狀態。因為 B 在收到 A 的消息的時候,可能已經過去了很長時間,B 在回消息的時候,A 可能已經不在線了,此時 B 是不能直接發數據的。如果 A 再給 B 回一個 ACK,B 就可以確認當前鏈路狀態了,這就變成了三次握手。

接下來說一下為什麼不是四次。既然三次已經可以保證建立可靠通信,就不需要額外的一次交互了。

 

下面是幾個生活中相關的示例:

 

 

 

 

 

 

 

 

 

 

 TCP 斷鏈四次揮手
1、a 時刻,A 向 B 發出 FIN 包,表示自己沒有數據要發送了
2、b 時刻,B 收到 FIN 包,回復 FIN ACK,表示收到了 A 的 FIN 包,不會再接收 A 的數據了
3、B 在發完 FIN ACK 后,可能還有數據要發給 A,這個數據是不能停止發送的,有數據還是需要繼續發送
4、d 時刻,B 發完了數據,也發出 FIN 包,告訴 A 自己的數據發完了,不再發送數據了
5、e 時刻,A 收到了 B 的 FIN 包,知道 B 也沒有數據要發送了,回復 FIN ACK。此時,連接可以斷開了

建連只需要交互三次,斷連卻需要四次,這是為什麼呢?其實斷開連接和建立連接還是不一樣的。建連的時候,只要雙方都告知對方自己準備好了就可以,但是斷連的時候,一方提出要斷開連接,不再發數據,另一方不能立即斷開,因為這一方可能還有數據要發送,直到數據全部發送完成后才能確認斷開。

 

下面是幾個生活中相關的示例:

 

 

 

以上是對於三次握手、四次揮手的簡單介紹,裏面沒有更詳細的狀態介紹,之後的博客會介紹,這裏先放兩張圖。
TCP 三次握手

 

 

 

TCP 四次揮手
 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

Postman之API測試使用全指南

Postman

Postman是一個可擴展的API開發和測試協同平台工具,可以快速集成到CI/CD管道中。旨在簡化測試和開發中的API工作流。

Postman 工具有 Chrome 擴展和獨立客戶端,推薦安裝獨立客戶端。

Postman 有個 workspace 的概念,workspace 分 personal 和 team 類型。Personal workspace 只能自己查看的 API,Team workspace 可添加成員和設置成員權限,成員之間可共同管理 API。

當然我個人使用一般是不登錄的,因為登錄之後會自動將你的測試歷史數據保存到賬戶里,你可以登陸網頁端進行查看。
因為API的很多數據是很敏感的,有的含有Token,或者就是一些私密信息,雖然Postman自己也強調說這樣很安全,不會私下窺探用戶的信息之類的,但是呢還是至少做一點有效的防範吧,自己不上傳,因為網絡並沒有絕對的安全。
所以我每次測試之後會將數據(Case)保存在本地,下次使用或者換設備的情況下將數據拷貝過來又可以繼續使用了。

下面正式開始介紹如何使用Postman吧。

為什麼選擇Postman?

如今,Postman的開發者已超過1000萬(來自官網),選擇使用Postman的原因如下:
簡單易用 – 要使用Postman,你只需登錄自己的賬戶,只要在電腦上安裝了Postman應用程序,就可以方便地隨時隨地訪問文件。
使用集合 – Postman允許用戶為他們的API調用創建集合。每個集合可以創建子文件夾和多個請求。這有助於組織測試結構。
多人協作 – 可以導入或導出集合和環境,從而方便共享文件。直接使用鏈接還可以用於共享集合。
創建環境 – 創建多個環境有助於減少測試重複(DEV/QA/STG/UAT/PROD),因為可以為不同的環境使用相同的集合。這是參數化發生的地方,將在後續介紹。
創建測試 – 測試檢查點(如驗證HTTP響應狀態是否成功)可以添加到每個API調用中,這有助於確保測試覆蓋率。
自動化測試 – 通過使用集合Runner或Newman,可以在多個迭代中運行測試,節省了重複測試的時間。
調試 – Postman控制台有助於檢查已檢索到的數據,從而易於調試測試。
持續集成——通過其支持持續集成的能力,可以維護開發實踐。

如何下載安裝Postman?

Step 1) 官網主頁:https://www.postman.com/downloads/, 下載所需版本進行安裝即可。

Step2)安裝完成之後會要求你必須登錄才能使用,沒有賬號可以進行註冊,註冊是免費的。(也可使用Google賬號,不過基本不能登錄,你懂的)

Step3)在Workspace選擇你要使用的工具並點擊“Save My Preferences”保存。

Step4)你將看到啟動后的頁面如下

如何使用Postman?

下圖是Postman的工作區間,各個模塊功能的介紹如下:

1、New,在這裏創建新的請求、集合或環境;還可以創建更高級的文檔、Mock Server 和 Monitor以及API。
2、Import,這用於導入集合或環境。有一些選項,例如從文件,文件夾導入,鏈接或粘貼原始文本。
3、Runner,可以通過Collection Runner執行自動化測試。後續介紹。
4、Open New,打開一個新的標籤,Postman窗口或Runner窗口。
5、My Workspace – 可以單獨或以團隊的形式創建新的工作區。
6、Invite – 通過邀請團隊成員在工作空間上進行協同工作。
7、History – 所有秦秋的歷史記錄,這樣可以很容易地跟蹤你所做的操作。
8、Collections – 通過創建集合來組織你的測試套件。每個集合可能有子文件夾和多個請求。請求或文件夾也可以被複制。
9、Request tab – 這將显示您正在處理的請求的標題。默認對於沒有標題的請求會显示“Untitled Request”。
10、HTTP Request – 單擊它將显示不同請求的下拉列表,例如 GET, POST, COPY, DELETE, etc. 在測試中,最常用的請求是GET和POST。
11、Request URL – 也稱為端點,显示API的URL。.
12、Save – 如果對請求進行了更改,必須單擊save,這樣新更改才不會丟失或覆蓋。
13、Params – 在這裏將編寫請求所需的參數,比如Key – Value。
14、Authorization – 為了訪問api,需要適當的授權。它可以是Username、Password、Token等形式。
15、Headers – 請求頭信息
16、Body – 請求體信息,一般在POST中才會使用到
17、Pre-request Script – 請求之前 先執行腳本,使用設置環境的預請求腳本來確保在正確的環境中運行測試。
18、Tests – 這些腳本是在請求期間執行的。進行測試非常重要,因為它設置檢查點來驗證響應狀態是否正常、檢索的數據是否符合預期以及其他測試。
19、Settings – 最新版本的有設置,一般用不到。

如何處理GET請求

Get請求用於從指定的URL獲取信息,不會對端點進行任何更改。
在這裏我們使用如下的URL作為演示:

https://jsonplaceholder.typicode.com/users	

在Postman的工作區中:
1、選擇HTTP請求方式為GET
2、在URL區域輸入 鏈接
3、點擊 “Send”按鈕
4、你將看到下方返回200狀態碼
5、在正文中應該有10個用戶結果,表明您的測試已經成功運行。

注意:在某些情況下,Get請求失敗可能由於URL無效或需要身份驗證。

如何處理POST請求

Post請求與Get請求不同,因為存在用戶向端點添加數據的數據操作。使用之前GET 請求中相同數據,現在添加我們自己的用戶。
Step 1)創建一個新請求

Step 2 )在新請求中
1、選擇HTTP請求方式為GET
2、在URL區域輸入 鏈接:https://jsonplaceholder.typicode.com/users
3、切換到Body選項

Step 3) Body選項
1、選中raw選項
2、選擇JSON

Step 4) 複製前面GET請求返回的json內容的第一節
更改id為11,更改name以及uesrname和email

[
    {
        "id": 11,
        "name": "Krishna Rungta",
        "username": "Bret",
        "email": "Sincere@april.biz
	",
        "address": {
            "street": "Kulas Light",
            "suite": "Apt. 556",
            "city": "Gwenborough",
            "zipcode": "92998-3874",
            "geo": {
                "lat": "-37.3159",
                "lng": "81.1496"
            }
        },
        "phone": "1-770-736-8031 x56442",
        "website": "hildegard.org",
        "company": {
            "name": "Romaguera-Crona",
            "catchPhrase": "Multi-layered client-server neural-net",
            "bs": "harness real-time e-markets"
        }
    }
]

注意: 檢查Body里用到的JSON格式很重要,以確保數據正確。
檢測的工具比如:https://jsonformatter.curiousconcept.com/

Step 5 )發送請求
1、完成上述的信息輸入,點擊Send按鈕
2、Status:應該是201,显示為創建成功
3、在Body里返回數據

如何將請求參數化

數據參數化是Postman最有用的特徵之一。你可以將使用到的變量進行參數化,而不是使用不同的數據創建相同的請求,這樣會事半功倍,簡潔明了。
這些數據可以來自數據文件環境變量。參數化有助於避免重複相同的測試,可用於自動化迭代測試。

參數通過使用雙花括號創建:{{sample}}
比如下面的請求:

接下來創建一個參數化get請求:
Step 1) 創建一個參數化get請求
1、將HTTP請求設置為GET
2、輸入URL: https://jsonplaceholder.typicode.com/users;將鏈接的域名部分替換為參數,例如{{url}}。請求url現在應該是{{url}}/users。
3、點擊Send按鈕。
應該沒有響應,因為我們沒有設置參數的源,如下圖:

Step 2) 使用環境設置所需的參數
1、點擊眼睛圖標
2、單擊Edit將該變量設置為可在所有集合中使用的全局環境。

Step 3) 變量–variable
1、將名稱設置為url,該url為https://jsonplaceholder.typicode.com
2、點擊保存按鈕

Step 4) 如果看到下面截圖的樣式,請單擊Close

Step 5 ) 回到你的Get請求頁面,然後單擊發送Send按鈕,Get請求應該就會返回結果了,如下圖:

注意:請確保所有的參數都有準確的源數據,不管是環境變量還是數據文件,以避免出錯。

如何創建Postman Tests

Postman Tests在請求中添加JavaScript代碼來協助驗證結果,如:成功或失敗狀態、預期結果的比較等等。
通常從pm.test開始。它可以與斷言相比較,驗證其他工具中可用的命令。
接下來創建一個包含Tests的請求:
Step 1) 創建一個Get請求
1、切換到Tests選項,右邊是代碼片段選項。
2、從右邊的代碼片段選項裏面選中 “Status code: Code is 200”
3、JS代碼就自動出現在窗口中

Step 2) 點擊發送請求按鈕。測試結果就显示出來了,如下圖:

Step 3) 回到Tests選項卡,讓我們添加另一個測試。這次我們將比較預期結果和實際結果。
在右邊的SNIPPETS區域選擇”Response body:JSON value check”選項,我們將檢查Leanne Graham是否擁有userid 1。

Step 4)
1、將代碼中的“Your Test Name”替換為“Check if user with id1 is Leanne Graham”,以便測試名稱確切描述我們想測試的內容。
2、使用jsonData[0].name代替jsonData.value; 獲取路徑,在獲取結果之前檢查Body。因為Leanne Graham是userid 1,所以jsonData在第一個結果中,這個結果應該從0開始。如果你想獲得第二個結果,那麼對後續結果使用jsonData[1] 即可。
3、在eql中,輸入“Leanne Graham”

pm.test("Check if user with id1 is Leanne Graham", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData[0].name).to.eql("Leanne Graham");
});

Step 5) 點擊發送請求,可以看到你的請求之後測試結果中有兩項显示測試通過。

注意:
有不同種類的測試可以在Postman中創建。嘗試探索這個工具,看看哪些測試適合你實際測試。

如何創建測試集合

集合在組織測試套件中扮演着重要的角色。它可以被導入和導出,使得在團隊之間共享集合變得很容易。在本教程中,我們將學習如何創建和執行集合。

Step 1) 單擊頁面左上角的New按鈕,如下圖:

Step 2) 選擇Collection(集合). 創建collection窗口彈出,如下圖.

Step 3) 輸入所需的集合名稱和描述,然後單擊create。
現在已經創建了一個集合。

Step 4 ) 和前面的Get請求一樣,點擊保存。

Step5 )
1、選擇Postman 測試集合(Test Collection)。
2、點擊保存Postman Test Collection

Step 6) Postman test collection現在應該包含了一個請求,如下圖:

Step 7) 重複上述的Step4-5,繼續創建請求,這樣,測試集合就應該有2個請求了,如下圖。

如何使用Collection Runner 運行集合

有兩種方式來運行一個集合,即Collection Runner和Newman。
Collection Runner:
Step 1) 單擊頁面頂部導入按鈕旁邊的Runner按鈕,如下圖。

Step 2)Collection Runner頁面應該出現如下所示。以下是對各個字段的描述

Step 3) 做如下設置,運行你的測試集合

  • 選擇Postman測試集合-集合迭代次數為3
  • 設置延遲為2500毫秒
  • 點擊Start Run按鈕

    Step 4) 單擊Run按鈕后將显示Run結果頁。根據延遲的不同,你應該在測試執行的同時看到显示的結果。

1、一旦測試完成,你就可以看到測試狀態是通過還是失敗,以及每個迭代的結果。
2、你將看到Get請求的Pass狀態;
3、由於我們沒有任何Post測試,所以應該會出現請求沒有任何測試的消息。

可以出在請求中進行測試是多麼重要,這樣你就可以驗證HTTP請求狀態是否成功,以及是否創建或檢索了數據。

如何使用Newman運行集合

運行集合的另一種方式是通過Newman。Newman和Collection Runner之間的主要區別如下:
1、Newman是Postman的替代品,所以需要單獨安裝Newman;
2、Newman使用命令行,而Collection Runner使用UI界面;
3、Newman可以用於持續集成。

安裝Newman並運行Collection,步驟如下:
Step 1) 下載並安裝NodeJs: http://nodejs.org/download/
Step 2) 打開命令行窗口並輸入下面命令:

npm install -g newman

安裝后 如下圖:

Step 3 )
Newman安裝好之後,讓我們回到Postman的workspace。在Collections框中,單擊三個點 會出現新的選擇選項,可看到Export選項,如下圖:

Step 4 )
選擇導出集合,默認使用推薦的集合版本,比如此處是v2.1,然後單擊導出:

Step 5 ) 選擇你想要保存的地址之後點擊保存,這裏建議專門新建一個文件夾來存放你的Postman tests。
Step 6 ) 另外還需要導出我們的環境(enviroment)。單擊全局環境下拉菜單旁邊的eye圖標,選擇JSON格式下載。選擇你想要的位置,然後單擊Save。最好將環境放在與Step5 導出的集合相同的文件夾中。

Step 7 ) 導出Environment 到集合文件夾后,現在回到命令行,將目錄更改為保存集合和環境的位置。

cd C:\Users\Asus\Desktop\Postman Tests

Step 8 ) 使用下面的命令運行你的測試集合:

newman run PostmanTestCollection.postman_collection.json -e Testing.postman_globals.json

運行的結果應該如下圖:

關於Newman的一些基礎指導如下:
1、只運行集合(如果沒有環境或測試數據文件依賴關係,則可以使用此選項。)

newman run <collection name> 

2、運行集合和環境(參數-e 是environment)

newman run <collection name> -e <environment name> 

3、使用所需的編號運行集合的迭代。

newman run <collection name> -n <no.of iterations>

4、運行數據文件

newman run <collection name> --data <file name>  -n <no.of iterations> -e <environment name> 

5、設置延遲時間。(這一點很重要,因為如果由於請求在後台服務器上,完成前一個請求時沒有延遲時間直接啟動下一個請求,測試可能會失敗。)

newman run <collection name> -d <delay time>

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

南投搬家前需注意的眉眉角角,別等搬了再說!

新北清潔公司,居家、辦公、裝潢細清專業服務

新春走基層·脫貧攻堅一線見聞:八百里瀚海的扶貧之路

  中國消費者報報道(記者李洪濤)噼!啪!清脆的爆竹聲不時在空中炸響。吉林省通榆縣蘇公坨鄉蘇公坨村六撮房屯,這個極具東北特色的小村莊到處散發著濃濃的年味。新春佳節前夕,《中國消費者報》新春走基層的記者跟隨當地市場監管部門的扶貧幹部,冒着零下23攝氏度嚴寒,踏着皚皚白雪,走進幫扶的貧困戶家中送上節日禮物。

  通榆縣地處吉林省西部,這裏常年乾旱少雨,風沙肆虐,自然環境惡劣,因地域廣闊,素有八百里瀚海之稱。該縣蘇公坨鄉蘇公坨村和巨寶山村,是兩個有着535個貧困戶的貧困村。在該縣脫貧攻堅工作中,通榆縣市場監督管理局勇挑重擔,對這兩個村實行包保脫貧。54歲的局黨委辦公室主任徐方樓任職駐村第一書記,如今已經4年。

  1月14日上午,天寒地凍。在駐村扶貧點簡陋的小平房裡,記者見到了面部黝黑、雙手長滿老繭,一身农民打扮的徐書記。

  據徐書記介紹,經過局裡幾年來的幫扶,蘇公坨村和巨寶山村的貧困戶基本上都實現了脫貧,目前,還有兩個因車禍及因病致貧的貧困戶還在积極幫扶中。當日上午,記者跟通榆縣市場監督管理局副局長趙洪亮一起,來到了這兩個貧戶家中進行了走訪。正值新春佳節,細心的扶貧幹部們為貧困戶們精心準備了大紅的燈籠、春聯,還有水果等年貨。雪野茫茫,鄉路彎彎,儘管岔路很多,但開車的食品檢驗檢測中心主任馬立群卻是十分地路熟。他風趣地說:“從春到冬,我們天天下鄉扶貧,路都記在心裏了。”

  當一行人來到蘇公坨村六撮房屯貧困戶白延軍家中時,64歲的劉金環老人正在給躺在炕上的老伴翻身。見到了徐方樓和馬立群,老人激動得連忙下炕,熱情地打着招呼。接過喜氣洋洋的大紅燈籠和寫着“家好人好運氣好,福旺財旺日子旺”的春聯時,她的眼裡噙着淚水。據徐方樓介紹,現年66歲的白延軍是一位退伍老兵。2018年7月30日早晨,他趕着毛驢車去地里幹活時,在村路上不幸被一輛物流公司的大貨車撞傷,雖然經搶救保住了性命,卻成了沒有任何知覺的植物人。由於在賠償上存在爭議,官司還處在人民法院的二審階段。從院里堆放的銹跡斑斑的各種農機具可以看出,在未出車禍前,劉延軍是個勤勞的人,一家人生活也比較富裕。記者在走訪中獲悉,白延軍一家的不幸遭遇,深深地牽動了市場監管部門幹部職工的心。大家踴躍捐款1.36萬元,春耕生產時還送上種子、化肥等生產資料。更重要的是,扶貧幹部們多次到家中看望,鼓勵一家人勇於面對困境,重拾生活信心。

  在巨寶山村巨寶山屯,45歲的农民張波動情地拉着扶貧幹部們連聲道謝。原來,他的女兒張鈺堔患有先天性成骨不全症,脆弱的雙腿稍不留意就會造成骨折,今年15歲了,已經骨折了十幾次。雖然身患重病,坐着輪椅,但小鈺堔聰明伶俐,樂觀向上,已經上了初中二年級的她學習成績優異。為了幫扶張波一家,扶貧幹部們協調有關部門,不僅對他家原有土平房進行了泥草房改造,還在村裡給他安排了一個協警的公益崗位,每年有1萬多元的收入。記者在張波家的牆上,看到貼着《扶貧攻堅幫扶提示板》,上面不僅有《扶貧手冊》,還有包保幹部的姓名和聯繫電話。

  在基層走訪,雖然天氣寒冷,但陽光明媚,空氣清新。歡聲笑語中,記者感受到了扶貧幹部和貧困戶之間濃濃的情意。在蘇公坨村黨支部委員會,一位中年婦女與扶貧幹部杜克峰熱情地打招呼,雙方十分熟識地拉着家常。該中年婦女名叫王艷,是楊樹林村的一名社主任。她告訴記者,她和這些城裡來的扶貧幹部親如兄妹。

  通榆縣是國家級貧困縣,脫貧攻堅任務艱巨。談到扶貧工作時,通榆縣市場監督管理局局長徐立忠說:“我們在扶貧攻堅方面做了很多細緻的工作。”據其介紹,該局對所包保的蘇公坨村和巨寶山村採取多項舉措。去年,倡議、組織愛心企業,為包保村捐款40.4萬元。(蘇公坨村28.5萬元,巨寶山村11.9萬元)。聯手白城市老年科協到蘇公坨村開展義診活動,向貧困群眾免費進行體檢,免費贈送價值1.75萬元的藥品。組織通榆縣益壽堂醫藥有限公司到蘇公坨村開展送醫送葯義診活動,免費提供價值3萬元的藥品。協調通榆縣農業銀行到蘇公坨村送電腦、打印機、紙張等14類辦公用品,價值1.2萬元。

  為了促進貧困人口增收,發展農村庭院經濟,該局給村民們購買了1.4萬元豆角籽。在改善人居環境上,購買2.6萬元的櫥櫃革、鐵絲、1萬根樹軸、7000株花苗。雇傭鏟車、鈎機、叉車、四輪車,對包保的兩村進行了環境衛生整治,美化了生活環境。在危房改造上,為貧困戶購買了1300米的電纜線,飲用水井房電錶一塊。中秋節,為蘇公坨村358戶、巨寶山村177戶貧困戶每戶送2公斤月餅。春節前夕,為兩村535戶貧困戶每戶送去5公斤蘋果、1桶食用油。此外,包保幹部們還自掏腰包,為貧困戶購買電視機、電視天線、玉米種子、輪椅、秧苗、藥品、米面油、食品、兒童玩具、雞雛、電飯鍋、櫥櫃等,积極開展結親、認親和幫親活動。在蘇公坨鄉敬老院,舉辦了以“敬老愛老”為主題的支部黨日活動,為老人們送水果、衣物、涼席等物品,併為老人理了發,打掃了敬老院院內外衛生,把溫暖送到孤寡老人心上,讓老人們感受到了黨的溫暖和關懷。

責任編輯:邊靜

本站聲明:網站內容來源再生能源資訊網http://www.ccn.com.cn/,如有侵權請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

新北清潔公司,居家、辦公、裝潢細清專業服務

Gogoro 計劃在美推出電動腳踏車「Gogoro Eeyo」,歐洲、台灣夏季登場

Gogoro 醞釀推出的全新服務「Gogoro Eeyo」有了最新消息,從 Gogoro Eeyo 社群帳號顯示,是來自 Gogoro 的電動腳踏車,預計 5 月於美國推出,歐洲、台灣則在夏季登場。

目前 Gogoro 官方已為 Gogoro Eeyo 開設社群帳號如 、、,在介紹中僅說明來自 Gogoro 的電動腳踏車,首發將在 5 月於美國推出,歐洲、台灣則預計在夏季登場,此外還加上表情符號來敘述,Gogoro 將從核心服務的電動機車,拓展到電動腳踏車的新領域。

Gogoro 在電動機車、換電系統、共享機車等領域發展成熟,然而目前針對 Gogoro Eeyo 尚未有更進一步的資訊,像是 Gogoro Eeyo 是自家設計或與他廠合作的電動腳踏車?其電動腳踏車有何特色功能?採用隨車充電還是 Gogoro Network 的電池交換網路?會有如同 GoShare 架構的共享腳踏車服務、或定點租還的「電動版 YouBike」、亦或只單賣電動腳踏車?疫情影響下 Gogoro 又將如何布局美國市場?

而從 Gogoro 向智慧財產局提交的商標資料加以推測,Gogoro Eeyo 外型可能與 Gogoro VIVA 相似,採充電系統而非換電方式;有獨立 App 可以控制,車上配有安全帽,還提供行車記錄的功能。

Gogoro Eeyo 整個產品或服務都令人好奇,筆者相信 Gogoro Eeyo 將讓不少台灣民眾期待,《科技新報》也將為讀者帶來後續報導。

(合作媒體:。首圖來源:)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

新北清潔公司,居家、辦公、裝潢細清專業服務

智慧充電管理軟體真的有效,加州電動交通車隊省下 40% 電費

隨著綠能推展,全球無數新創事業應運而生,宣稱智慧軟體能在能源多元化時代為顧客省錢,也包括電動車隊的智慧充電管理系統,這些系統真能達到宣稱的效益嗎?如今第一波實際使用的成果已逐漸顯現。新創事業 Amply Power 於 2020 年 4 月發表系統應用於北加州康特拉科斯塔郡 Tri Delta 交通車隊電動車的成效,自 2020 年初以來,為車隊節省了 40% 電費。

隨著都市市區環保意識上升,以及各國推動減碳,加上電池降價使得電動車購置成本降低,越來越多公車與交通車隊改用電動車,目前全球有超過 200 家交通車隊採用電動車,並預計到 2025 年電動巴士將占全球交通車隊 30%。

Tri Delta 早在 2018 年就已經開始加入潮流,當時只先測試 4 輛電動車,2 輛來自比亞迪、2 輛來自加州電動巴士廠 Proterra,即使只是先測試 4 輛,對車隊的後勤作業就造成相當大的改變。少了 4 輛車需要柴油與一般引擎車的維修,但多出與電力公司交涉、升級變電器、安裝高壓電力裝置等任務,僅 4 輛車就導致最高電力需求負載高達 300 千瓦,這下突然得處理很多過去不曾想過的電力節費問題。

於是 2019 年底 Tri Delta 決定採用 Amply Power 的智慧充電管理軟體,由軟體管理充電時間,挑選電費較低的離峰時間充電,以節省電費,但又同時確保要用車的時候電力有充飽,車隊後勤人員不再需要思考何時插上充電座比較省錢,讓軟體決定就好了。此外,改採電動車之後,最大的困擾就是一旦充電沒有插好,等到隔天要用車,車子沒電才發現,就會造成調度嚴重問題,使用充電管理軟體後,充電若沒插好,軟體會發出警告,一勞永逸解決了這個防呆問題。

充電管理結果能否擴大適用還待驗證

使用充電管理軟體的期間,Tri Delta 的電力公司太平洋瓦電(PG&E)調整過尖峰用電時間表,Tri Delta 本身用電變化也讓所屬費率區間有變動,過去這些都會造成負責充電的員工傷透腦筋,每週的最佳充電時間都不同,一不小心就讓公司承受高額電費,這些變動更顯出充電管理軟體的重要性,充電管理軟體會自動依據電力公司的時間表與公式調整,算出最划算的充電時間。

經過幾個月使用下來,Tri Delta 節省了高達 40% 電費支出,這還只是第一季,進入夏季後,尖峰用電費率落差更大,會讓充電管理的效益更明顯。

不過,這僅是 4 輛電動車的充電管理結果,能否擴大適用到上百台規模的大車隊,尚需進一步驗證。不過越大的車隊,原理上來說,充電管理能達到的效益會更顯著,不僅節省電費更多,軟體最佳化分配車輛充電的時間,更可以讓硬體投資也跟著減少,例如設置較少充電座,或讓電力設備不需太大規模升級,節省建設成本與工程時間。

Amply Power 此實證案例,不僅證明充電管理的重要性,為許多管理軟體新創事業開創市場,另一方面,也同時為整個電動車產業打了一劑定心針:電動巴士車隊雖然成本較高,但可仰賴電費比燃料費用便宜來達成經濟效益,如今這商業模式面臨挑戰,因油價在全球新冠病毒疫情影響下降到低點,電動車的費用優勢可能消失,但是,若充電管理能省下 40% 電費,那麼,電動車隊尚可取回一部分競爭優勢。

(合作媒體:。首圖來源:)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

吃到飽變吃不飽?電動機車商用資費為何如此難算?

近日 Gogoro 電池月租吃到飽方案引發爭議,對於如何定義商用,以及如何舉證開罰,各界都有不同看法,但 Gogoro 先是強調不再寬待,昨夜又臨時發表聲明政策轉彎,然而品牌形象已經產生傷害。究竟 Gogoro 為何如此堅持,而電動機車的資費又應該怎麼設計會更合理呢?

近日由於網友貼出了一張 Gogoro 寄送的「違規使用通知信」,而讓吃到飽方案成為爭論焦點。我們快速整理一下目前的重點。

  1. Gogoro 月租 899 吃到飽方案,禁止商業使用。
  2. 連續兩個月里程超過 1,600 公里,將被視為商業使用而開罰。
  3. 用戶收到通知後,可以回寄照片證明是用於出遊或長程通勤,即可免罰。
  4. 有路人開始檢舉外送員騎 gogoro 送餐。
  5. Gogoro 發公開信,5/10 起若被檢舉,無論里程長短,將直接變更為商用方案。
  6. Gogoro 修改標準,需連續兩個月里程超過 1,600 公里且被檢舉商業使用才開罰。

且不談這次資費爭議,我們此時可以想的一件事情是,如果燃油車終將被淘汰,電動車需要怎樣的能源費用標準才合理?

假設以每月 1,600 公里為使用里程來計算,目前各種能源方案以 Gogoro 商業型最貴,七期燃油車最便宜,充電式機車在光陽調降月租費用之後,如果採用兩顆電池方案,再加上全部在家充電,費用也相當便宜。

每月騎 1,600 公里,機車能源費用比較。(圖片來源:科技新報製)

不過 IONEX 方案並未說明是否可作為商業使用,而且月租費 398 方案限定綁約兩年,期滿後回到原價 598 元,這個方案還提供 2,000 公里里程,算是相當優惠,如果能夠在家充電的話,是一個不錯的選項。(充電時間約 4 小時)

而燃油車在油價狂降的此刻,商用優勢更為明顯,即使九五汽油價格回升到 30 元,每月費用仍然不到一千元,當然前提是要騎乘七期燃油車,才有每公升 50 公里的低油耗表現。

Gogoro 商業方案的天價,讓人望之卻步,為什麼會訂出這麼高的金額呢?雖然 Gogoro 官方並未明說,但顯然換電站建置與電池成本,如果在頻繁換電情況下,確實讓 Gogoro 電網不堪負荷,而原本換電的優勢也因為電池來不及充飽而打折,因此官方才祭出強硬手腕。

Gogoro 第二次政策轉彎,重新定義吃到飽違約標準。(Source:)

但 Gogoro 滿街跑對於官方來說又是最佳宣傳,所以之前才會容許模糊地帶存在,但是當其他車主開始檢舉之後,官方也不得不有所回應。經過兩次轉彎,最新的定調是,連續兩個月里程超過 1,600 公里且經檢舉才會視為商業使用。換句話說,如果偶爾兼差外送,並不會被追討違約金。

按照 Gogoro 官方說法,為了 99% 的用戶著想,他們願意放寬認定標準,但也看得出來,換電站與電池流通量不足,才是這次爭議真正的核心。否則何必為了 0.3% 的極少數用戶,而鬧出滿城風雨。

而充電式機車像是 e-moving 推出的商用版 ie PICKUP,則看準 Gogoro 在這個領域的不足,期望能夠搶佔商用電動機車市場,電池租賃方案分別為 399 元/月基礎型(家充不限里程)、599 元/月輕量型提供 100 分鐘超級充電時數、799 元/月進階型提供 400 分鐘,合約皆為 2 年一簽,車輛定價則為 83,800 元。

光陽 IONEX 的電池租用方案費用較低,但需要用戶自行在家充電,或是找快充站付費充電。(圖片來源:)

那麼充電式機車會是商用機車的新未來嗎?這仍要取決於未來充電式機車的性能是否有充足進步,以 IONEX 為例,定價 66,800 元新台幣,極速在 60 km/h 以下,在理想狀態下的滿電續航里程為 60 km,而快充到滿需要一個小時(額外付費),要作為商業使用,恐怕還有所不足。更何況當前資費方案,其實是因為用戶量極少,才推出的短期優惠,未來如果用戶增加,會否漲價,或是加入禁止商用條款也未可知。

電動車要商用化的另一項挑戰,來自於維修保養體系,對於商業用戶來說,時間就是金錢,而據點少、難預約的電動機車服務站,在這一點就輸給發展許久的油車一大截了。

以目前兩種電動機車的型態來看,換電系統對於使用者來說比較符合商用需求,但營運商成本較高;充電系統雖然有價格優勢,卻輸在車輛性能與時間彈性上。在可見的將來,全面禁用燃油車幾乎已是定局,若要讓商用機車能夠全面電動化,勢必需要更多的基礎建設(充電站、換電站、保修據點)才能拉低成本與里程焦慮,在那之前,恐怕難有比現在更好的作法。

最終我們建議,Gogoro 不該繼續在模糊地帶打轉,而是仔細估算商用方案的定價,相信如果能夠將方案價格調降到 1,500 元以下,或是與外送平台、快遞業者合作推優惠方案,讓商用族群可以正正當當的「吃到飽」,而不是每個月精算里程才是正途。試想,如果滿街的外送員都騎電動車,不正是電動車的一大勝利嗎?

(合作媒體:。首圖來源:)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

南投搬家前需注意的眉眉角角,別等搬了再說!

新北清潔公司,居家、辦公、裝潢細清專業服務

SpringBoot2.x的依賴管理

前提

這篇文章是《SpringBoot2.x入門》專輯的第1篇文章,使用的SpringBoot版本為2.3.1.RELEASEJDK版本為1.8

主要梳理一下SpringBoot2.x的依賴關係和依賴的版本管理,依賴版本管理是開發和管理一個SpringBoot項目的前提。

SpringBoot其實是通過starter的形式,對spring-framework進行裝箱,消除了(但是兼容和保留)原來的XML配置,目的是更加便捷地集成其他框架,打造一個完整高效的開發生態。

SpringBoot依賴關係

因為個人不太喜歡Gradle,所以下文都以Maven舉例。

SpringCloud的版本(SpringCloud的正式版是用倫敦地鐵站或者說倫敦某地名的英文名稱作為版本號,例如比較常用的F版本Finchley就是位於倫敦北部芬奇利)管理不同,SpringBoot的依賴組件發布版本格式是:X.Y.Z.RELEASE。因為SpringBoot組件一般會裝箱為starter,所以組件的依賴GAV一般為:org.springframework.boot:spring-boot-starter-${組件名}:X.Y.Z.RELEASE,其中X是主版本,不同的主版本意味着可以放棄兼容性,也就是SpringBoot1.xSpringBoot2.x不保證兼容性,而組件名一般是代表一類中間件或者一類功能,如data-redisspring-boot-starter-data-redis,提供Redis訪問功能)、jdbcspring-boot-starter-jdbc,提供基於JDBC驅動訪問數據庫功能)等等。以SpringBoot當前最新的發布版本2.3.1.RELEASEorg.springframework.boot:spring-boot-starter:jar:2.3.1.RELEASE為例,用mvn dependency:tree分析它的依賴關係如下:

這個依賴樹也印證了starter是基於Spring項目裝箱和擴展的。

SpringBoot依賴管理

如果使用Spring Initializr創建一個SpringBoot項目的話,那麼會發現項目的POM文件中會加入了一個parent元素:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.3.1.RELEASE</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

其實spring-boot-starter-parent相當於作為了當前項目的父模塊,在父模塊裏面管理了當前指定的SpringBoot版本2.3.1.RELEASE所有依賴的第三方庫的統一版本管理,通過spring-boot-starter-parent上溯到最頂層的項目,會找到一個properties元素,裏面統一管理Spring框架和所有依賴到的第三方組件的統一版本號,這樣就能確保對於一個確定的SpringBoot版本,它引入的其他starter不再需要指定版本,同時所有的第三方依賴的版本也是固定的。如項目的POM文件如下:

<!-- 暫時省略其他的配置屬性 -->
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.3.1.RELEASE</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>
<groupId>com.example</groupId>
<artifactId>demo</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>demo</name>
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
        <exclusions>
            <exclusion>
                <groupId>org.junit.vintage</groupId>
                <artifactId>junit-vintage-engine</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
</dependencies>

這樣只需要修改parent元素中的版本號,就能全局更變所有starter的版本號。這種做法其實本質上是把當前項目作為spring-boot-starter-parent的子項目,其實在一定程度上並不靈活。這裏推薦使用另一種方式:通過dependencyManagement元素全局管理SpringBoot版本,適用於單模塊或者多模塊的Maven項目。項目的(父)POM文件如下:

<!-- spring-boot-guide 父POM -->
<properties>
    <spring.boot.version>2.3.1.RELEASE</spring.boot.version>
</properties>
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>${spring.boot.version}</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>

然後需要用到其他starter的時候,只需要在dependencies直接引入即可,不再需要指定版本號,版本號由dependencyManagement中定義的版本號統一管理。

<!-- spring-boot-guide/ch0-dependency 子POM -->
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
    </dependency>
</dependencies>

SpringBoot依賴覆蓋

有些特殊的情況,可能項目中大部分的starter使用的是相對低的版本,但是由於部分新的功能需要使用到更高版本的個別starter,則需要強制引入該高版本的starter。這裏舉一個例子,項目用到的SpringBoot組件的版本是2.1.5.RELEASE,使用的中間件服務Elasticsearch的版本是7.x,而spring-boot-starter-data-elasticsearch支持的版本如下:

理論上可以一下子升級SpringBoot2.3.1.RELEASE,其實也可以直接指定spring-boot-starter-data-elasticsearch的版本覆蓋掉全局的SpringBoot組件版本,這裏應用了Maven依賴調解原則

<!-- 父POM或者全局POM -->
<properties>
    <spring.boot.version>2.1.5.RELEASE</spring.boot.version>
</properties>
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>${spring.boot.version}</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-elasticsearch</artifactId>
        <version>2.3.1.RELEASE</version>
    </dependency>
</dependencies>

這樣就能單獨提升spring-boot-starter-data-elasticsearch的版本為2.3.1.RELEASE,其他組件的版本依然保持為2.1.5.RELEASE

小結

目前有兩種常用的方式管理SpringBoot組件的版本(兩種方式二選一):

  1. 配置parent元素,通過項目繼承的方式指定SpringBoot組件的版本號,這是Spring Initializr生成的項目中默認的配置方式。
  2. 配置dependencyManagement元素(推薦此方式),通過(父)POM文件統一指定SpringBoot組件的版本號。

另外,SpringBoot1.x2.x之間有兼容性問題(最明顯的一點是2.x中刪除了1.x中大量的內建類,如果用到了這些SpringBoot中的內建類,容易出現ClassNotFoundException),降級或者升級都有比較大的風險。一般情況下,建議使用同一個大版本進行項目開發,如果確定需要進行大版本切換,請務必做完畢的功能測試。

(本文完 c-1-d e-a-20200628)

技術公眾號(《Throwable文摘》,id:throwable-doge),不定期推送筆者原創技術文章(絕不抄襲或者轉載):

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

新北清潔公司,居家、辦公、裝潢細清專業服務

pythonic context manager知多少

Context Managers 是我最喜歡的 python feature 之一,在恰當的時機使用 context manager 使代碼更加簡潔、清晰,更加安全,復用性更好,更加 pythonic。本文簡單介紹一下其使用方法以及常見使用場景。

本文地址:https://www.cnblogs.com/xybaby/p/13202496.html

with statement and context manager

Python’s with statement supports the concept of a runtime context defined by a context manager

new statement “with” to the Python language to make it possible to factor out standard uses of try/finally statements.

在 pep0343 中,通過引入 context manager protocol 來支持 With statement , context manager 是用來管理 context(上下文)的,即保證程序要保持一種特定的狀態 — 無論是否發生異常。可以說,context manager 簡化了對 try-finally 的使用,而且更加安全,更加便於使用。

Transforming Code into Beautiful, Idiomatic Python 中,指出了 context manager 的最顯著的優點:

  • Helps separate business logic from administrative logic
  • Clean, beautiful tools for factoring code and improving code reuse

最廣為人知的例子,就是通過 with statement 來讀寫文件,代碼如下:

with open('test.txt') as f:
    contect = f.read()
    handle_content(content)

上面的代碼幾乎等價於

f = open('test.txt') 
try:
    contect = f.read()
    handle_content(content)
finally:
    f.close()

注意,上面的finally的作用就是保證file.close一定會被調用,也就是資源一定會釋放。不過,很多時候,都會忘了去寫這個finally,而 with statement 就徹底避免了這個問題。

從上述兩段代碼也可以看出,with statement 更加簡潔,而且將核心的業務邏輯(從文件中讀取、處理數據)與其他邏輯(打開、關係文件)相分離,可讀性更強。

實現context manager protocol

一個類只要定義了__enter____exit__方法就實現了context manager 協議

object.__enter__(self)
Enter the runtime context related to this object. The with statement will bind this method’s return value to the target(s) specified in the as clause of the statement, if any.

object.__exit__(self, exc_type, exc_value, traceback)
Exit the runtime context related to this object. The parameters describe the exception that caused the context to be exited. If the context was exited without an exception, all three arguments will be None.

If an exception is supplied, and the method wishes to suppress the exception (i.e., prevent it from being propagated), it should return a true value. Otherwise, the exception will be processed normally upon exit from this method.

Note that __exit__() methods should not reraise the passed-in exception; this is the caller’s responsibility.

__enter__方法在進入這個 context 的時候調用,返回值賦值給 with as X 中的 X

__exit__方法在退出 context 的時候調用,如果沒有異常,后三個參數為 None。如果返回值為 True,則Suppress Exception,所以除非特殊情況都應返回 False。另外注意, __exit__方法本身不應該拋出異常。

例子:BlockGuard

在看c++代碼(如mongodb源碼)的時候,經常看見其用 RAII 實現BlockGuard, 用以保證在離開 Block 的時候執行某些動作,同時,也提供手段來取消執行。

下面用python實現一下:

class BlockGuard(object):
	def __init__(self, fn, *args, **kwargs):
		self._fn = fn
		self._args = args
		self._kwargs = kwargs
		self._canceled = False

	def __enter__(self):
		return self

	def __exit__(self, exc_type, exc_value, traceback):
		if not self._canceled:
			self._fn(*self._args, **self._kwargs)
		self._fn = None
		self._args = None
		self._kwargs = None
		return False

	def cancel(self):
		self._canceled = True


def foo():
	print 'sth should be called'


def test_BlockGuard(cancel_guard):
	print 'test_BlockGuard'
	with BlockGuard(foo) as guard:
		if cancel_guard:
			guard.cancel()
	print 'test_BlockGuard  finish'

用yield實現context manager

標準庫 contextlib 中提供了一些方法,能夠簡化我們使用 context manager,如 contextlib.contextmanager(func) 使我們
無需再去實現一個包含__enter__ __exit__方法的類。

The function being decorated must return a generator-iterator when called. This iterator must yield exactly one value, which will be bound to the targets in the with statement’s as clause, if any.

例子如下:

from contextlib import contextmanager

@contextmanager
def managed_resource(*args, **kwds):
    # Code to acquire resource, e.g.:
    resource = acquire_resource(*args, **kwds)
    try:
        yield resource
    finally:
        # Code to release resource, e.g.:
        release_resource(resource)

>>> with managed_resource(timeout=3600) as resource:
...     # Resource is released at the end of this block,
...     # even if code in the block raises an exception

需要注意的是:

  • 一定要寫 try finally,才能保證release_resource邏輯一定被調用
  • 除非特殊情況,不再 catch exception,這就跟 __exit__ 一般不返回True一樣

例子: no_throw

這是業務開發中的一個需求, 比如觀察者模式,不希望因為其中一個觀察者出了 trace 就影響後續的觀察者,就可以這樣做:

from contextlib import contextmanager

@contextmanager
def no_throw(*exceptions):
	try:
		yield
	except exceptions:
		pass

def notify_observers(seq):
	for fn in [sum, len, max, min]:
		with no_throw(Exception):
			print "%s result %s" % (fn.__name__, fn(seq))

if __name__ == '__main__':
	notify_observers([])

在python 3.x 的 contexlib 中,就提供了一個contextlib.suppress(*exceptions), 實現了同樣的效果。

context manager 應用場景

context manager 誕生的初衷就在於簡化 try-finally,因此就適合應用於在需要 finally 的地方,也就是需要清理的地方,比如

  • 保證資源的安全釋放,如 file、lock、semaphore、network connection 等
  • 臨時操作的復原,如果一段邏輯有 setup、prepare,那麼就會對應 cleanup、teardown。

對於第一種情況,網絡連接釋放的例子,後面會結合 pymongo 的代碼展示。

在這裏先來看看第二種用途:保證代碼在一個臨時的、特殊的上下文(context)中執行,且在執行結束之後恢復到之前的上下文環境。

改變工作目錄

from contextlib import contextmanager
import os

@contextmanager
def working_directory(path):
    current_dir = os.getcwd()
    os.chdir(path)
    try:
        yield
    finally:
        os.chdir(current_dir)

with working_directory("data/stuff"):
    pass

臨時文件、文件夾

很多時候會產生一堆臨時文件,比如build的中間狀態,這些臨時文件都需要在結束之後清除。

from tempfile import mkdtemp
from shutil import rmtree

@contextmanager
def temporary_dir(*args, **kwds):
    name = mkdtemp(*args, **kwds)
    try:
        yield name
    finally:
        shutil.rmtree(name)

with temporary_dir() as dirname:
    pass

重定向標準輸出、標準錯誤

@contextmanager
def redirect_stdout(fileobj):
    oldstdout = sys.stdout
    sys.stdout = fileobj
    try:
        yield fieldobj
    finally:
        sys.stdout = oldstdout

在 python3.x 中,已經提供了 contextlib.redirect_stdout contextlib.redirect_stderr 實現上述功能

調整logging level

這個在查問題的適合非常有用,一般生產環境不會輸出 debug level 的日誌,但如果出了問題,可以臨時對某些制定的函數調用輸出debug 日誌

from contextlib import contextmanager
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

ch = logging.StreamHandler()
ch.setFormatter(logging.Formatter('%(asctime)s - %(levelname)s - %(message)s'))
logger.addHandler(ch)


@contextmanager
def change_log_level(level):
	old_level = logger.getEffectiveLevel()
	try:
		logger.setLevel(level)
		yield
	finally:
		logger.setLevel(old_level)


def test_logging():
	logger.debug("this is a debug message")
	logger.info("this is a info message")
	logger.warn("this is a warning message")

with change_log_level(logging.DEBUG):
	test_logging()

pymongo中的context manager使用

在 pymongo 中,封裝了好幾個 context manager,用以

  • 管理 semaphore
  • 管理 connection
  • 資源清理

而且,在 pymongo 中,給出了嵌套使用 context manager 的好例子,用來保證 socket 在使用完之後一定返回連接池(pool)。

# server.py
@contextlib.contextmanager
def get_socket(self, all_credentials, checkout=False):
    with self.pool.get_socket(all_credentials, checkout) as sock_info:
        yield sock_info
        
# pool.py
@contextlib.contextmanager
def get_socket(self, all_credentials, checkout=False):
    sock_info = self._get_socket_no_auth()
    try:
        sock_info.check_auth(all_credentials)
        yield sock_info
    except:
        # Exception in caller. Decrement semaphore.
        self.return_socket(sock_info)
        raise
    else:
        if not checkout:
            self.return_socket(sock_info)

可以看到,server.get_socket 調用了 pool.get_socket, 使用 server.get_socket 的代碼完全不了解、也完全不用關心 socket 的釋放細節,如果把 try-except-finally-else 的邏輯移到所有使用socket的地方,代碼就會很醜、很臃腫。

比如,在mongo_client 中需要使用到 socket:

with server.get_socket(all_credentials) as sock_info:
    sock_info.authenticate(credentials)

references

With statement

Context Managers

contextlib

what-is-the-python-with-statement-designed-for

Transforming Code into Beautiful, Idiomatic Python

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

Python 圖像處理 OpenCV (12): Roberts 算子、 Prewitt 算子、 Sobel 算子和 Laplacian 算子邊緣檢測技術

前文傳送門:

「Python 圖像處理 OpenCV (1):入門」

「Python 圖像處理 OpenCV (2):像素處理與 Numpy 操作以及 Matplotlib 显示圖像」

「Python 圖像處理 OpenCV (3):圖像屬性、圖像感興趣 ROI 區域及通道處理」

「Python 圖像處理 OpenCV (4):圖像算數運算以及修改顏色空間」

「Python 圖像處理 OpenCV (5):圖像的幾何變換」

「Python 圖像處理 OpenCV (6):圖像的閾值處理」

「Python 圖像處理 OpenCV (7):圖像平滑(濾波)處理」

「Python 圖像處理 OpenCV (8):圖像腐蝕與圖像膨脹」

「Python 圖像處理 OpenCV (9):圖像處理形態學開運算、閉運算以及梯度運算」

「Python 圖像處理 OpenCV (10):圖像處理形態學之頂帽運算與黑帽運算」

「Python 圖像處理 OpenCV (11):Canny 算子邊緣檢測技術」

引言

前文介紹了 Canny 算子邊緣檢測,本篇繼續介紹 Roberts 算子、 Prewitt 算子、 Sobel 算子和 Laplacian 算子等常用邊緣檢測技術。

Roberts 算子

Roberts 算子,又稱羅伯茨算子,是一種最簡單的算子,是一種利用局部差分算子尋找邊緣的算子。他採用對角線方向相鄰兩象素之差近似梯度幅值檢測邊緣。檢測垂直邊緣的效果好於斜向邊緣,定位精度高,對噪聲敏感,無法抑制噪聲的影響。

1963年, Roberts 提出了這種尋找邊緣的算子。 Roberts 邊緣算子是一個 2×2 的模版,採用的是對角方向相鄰的兩個像素之差。

Roberts 算子的模板分為水平方向和垂直方向,如下所示,從其模板可以看出, Roberts 算子能較好的增強正負 45 度的圖像邊緣。

\[dx = \left[ \begin{matrix} -1 & 0\\ 0 & 1 \\ \end{matrix} \right] \]

\[dy = \left[ \begin{matrix} 0 & -1\\ 1 & 0 \\ \end{matrix} \right] \]

Roberts 算子在水平方向和垂直方向的計算公式如下:

\[d_x(i, j) = f(i + 1, j + 1) – f(i, j) \]

\[d_y(i, j) = f(i, j + 1) – f(i + 1, j) \]

Roberts 算子像素的最終計算公式如下:

\[S = \sqrt{d_x(i, j)^2 + d_y(i, j)^2} \]

今天的公式都是小學生水平,千萬別再說看不懂了。

實現 Roberts 算子,我們主要通過 OpenCV 中的 filter2D() 這個函數,這個函數的主要功能是通過卷積核實現對圖像的卷積運算:

def filter2D(src, ddepth, kernel, dst=None, anchor=None, delta=None, borderType=None)
  • src: 輸入圖像
  • ddepth: 目標圖像所需的深度
  • kernel: 卷積核

接下來開始寫代碼,首先是圖像的讀取,並把這個圖像轉化成灰度圖像,這個沒啥好說的:

# 讀取圖像
img = cv.imread('maliao.jpg', cv.COLOR_BGR2GRAY)
rgb_img = cv.cvtColor(img, cv.COLOR_BGR2RGB)

# 灰度化處理圖像
grayImage = cv.cvtColor(img, cv.COLOR_BGR2GRAY)

然後是使用 Numpy 構建卷積核,並對灰度圖像在 x 和 y 的方向上做一次卷積運算:

# Roberts 算子
kernelx = np.array([[-1, 0], [0, 1]], dtype=int)
kernely = np.array([[0, -1], [1, 0]], dtype=int)

x = cv.filter2D(grayImage, cv.CV_16S, kernelx)
y = cv.filter2D(grayImage, cv.CV_16S, kernely)

注意:在進行了 Roberts 算子處理之後,還需要調用convertScaleAbs()函數計算絕對值,並將圖像轉換為8位圖進行显示,然後才能進行圖像融合:

# 轉 uint8 ,圖像融合
absX = cv.convertScaleAbs(x)
absY = cv.convertScaleAbs(y)
Roberts = cv.addWeighted(absX, 0.5, absY, 0.5, 0)

最後是通過 pyplot 將圖像显示出來:

# 显示圖形
titles = ['原始圖像', 'Roberts算子']
images = [rgb_img, Roberts]

for i in range(2):
    plt.subplot(1, 2, i + 1), plt.imshow(images[i], 'gray')
    plt.title(titles[i])
    plt.xticks([]), plt.yticks([])
plt.show()

最終結果如下:

Prewitt 算子

Prewitt 算子是一種一階微分算子的邊緣檢測,利用像素點上下、左右鄰點的灰度差,在邊緣處達到極值檢測邊緣,去掉部分偽邊緣,對噪聲具有平滑作用。

由於 Prewitt 算子採用 3 * 3 模板對區域內的像素值進行計算,而 Robert 算子的模板為 2 * 2 ,故 Prewitt 算子的邊緣檢測結果在水平方向和垂直方向均比 Robert 算子更加明顯。Prewitt算子適合用來識別噪聲較多、灰度漸變的圖像。

Prewitt 算子的模版如下:

\[dx = \left[ \begin{matrix} 1 & 0 & -1\\ 1 & 0 & -1\\ 1 & 0 & -1\\ \end{matrix} \right] \]

\[dy = \left[ \begin{matrix} -1 & -1 & -1\\ 0 & 0 & 0\\ 1 & 1 & 1\\ \end{matrix} \right] \]

在代碼實現上, Prewitt 算子的實現過程與 Roberts 算子比較相似,我就不多介紹,直接貼代碼了:

import cv2 as cv
import numpy as np
import matplotlib.pyplot as plt

# 讀取圖像
img = cv.imread('maliao.jpg', cv.COLOR_BGR2GRAY)
rgb_img = cv.cvtColor(img, cv.COLOR_BGR2RGB)

# 灰度化處理圖像
grayImage = cv.cvtColor(img, cv.COLOR_BGR2GRAY)

# Prewitt 算子
kernelx = np.array([[1,1,1],[0,0,0],[-1,-1,-1]],dtype=int)
kernely = np.array([[-1,0,1],[-1,0,1],[-1,0,1]],dtype=int)

x = cv.filter2D(grayImage, cv.CV_16S, kernelx)
y = cv.filter2D(grayImage, cv.CV_16S, kernely)

# 轉 uint8 ,圖像融合
absX = cv.convertScaleAbs(x)
absY = cv.convertScaleAbs(y)
Prewitt = cv.addWeighted(absX, 0.5, absY, 0.5, 0)

# 用來正常显示中文標籤
plt.rcParams['font.sans-serif'] = ['SimHei']

# 显示圖形
titles = ['原始圖像', 'Prewitt 算子']
images = [rgb_img, Prewitt]

for i in range(2):
    plt.subplot(1, 2, i + 1), plt.imshow(images[i], 'gray')
    plt.title(titles[i])
    plt.xticks([]), plt.yticks([])
plt.show()

從結果上來看, Prewitt 算子圖像銳化提取的邊緣輪廓,其效果圖的邊緣檢測結果比 Robert 算子更加明顯。

Sobel 算子

Sobel 算子的中文名稱是索貝爾算子,是一種用於邊緣檢測的離散微分算子,它結合了高斯平滑和微分求導。

Sobel 算子在 Prewitt 算子的基礎上增加了權重的概念,認為相鄰點的距離遠近對當前像素點的影響是不同的,距離越近的像素點對應當前像素的影響越大,從而實現圖像銳化並突出邊緣輪廓。

算法模版如下:

\[dx = \left[ \begin{matrix} 1 & 0 & -1\\ 2 & 0 & -2\\ 1 & 0 & -1\\ \end{matrix} \right] \]

\[dy = \left[ \begin{matrix} -1 & -2 & -1\\ 0 & 0 & 0\\ 1 & 2 & 1\\ \end{matrix} \right] \]

Sobel 算子根據像素點上下、左右鄰點灰度加權差,在邊緣處達到極值這一現象檢測邊緣。對噪聲具有平滑作用,提供較為精確的邊緣方向信息。因為 Sobel 算子結合了高斯平滑和微分求導(分化),因此結果會具有更多的抗噪性,當對精度要求不是很高時, Sobel 算子是一種較為常用的邊緣檢測方法。

Sobel 算子近似梯度的大小的計算公式如下:

\[G = \sqrt{d_X^2 + d_y^2} \]

梯度方向的計算公式如下:

\[\theta = \tan^{-1}(\frac {d_x}{d_y}) \]

如果以上的角度 θ 等於零,即代表圖像該處擁有縱向邊緣,左方較右方暗。

在 Python 中,為我們提供了 Sobel() 函數進行運算,整體處理過程和前面的類似,代碼如下:

import cv2 as cv
import matplotlib.pyplot as plt

# 讀取圖像
img = cv.imread('maliao.jpg', cv.COLOR_BGR2GRAY)
rgb_img = cv.cvtColor(img, cv.COLOR_BGR2RGB)

# 灰度化處理圖像
grayImage = cv.cvtColor(img, cv.COLOR_BGR2GRAY)

# Sobel 算子
x = cv.Sobel(grayImage, cv.CV_16S, 1, 0)
y = cv.Sobel(grayImage, cv.CV_16S, 0, 1)

# 轉 uint8 ,圖像融合
absX = cv.convertScaleAbs(x)
absY = cv.convertScaleAbs(y)
Sobel = cv.addWeighted(absX, 0.5, absY, 0.5, 0)

# 用來正常显示中文標籤
plt.rcParams['font.sans-serif'] = ['SimHei']

# 显示圖形
titles = ['原始圖像', 'Sobel 算子']
images = [rgb_img, Sobel]

for i in range(2):
    plt.subplot(1, 2, i + 1), plt.imshow(images[i], 'gray')
    plt.title(titles[i])
    plt.xticks([]), plt.yticks([])
plt.show()

Laplacian 算子

拉普拉斯( Laplacian )算子是 n 維歐幾里德空間中的一個二階微分算子,常用於圖像增強領域和邊緣提取。

Laplacian 算子的核心思想:判斷圖像中心像素灰度值與它周圍其他像素的灰度值,如果中心像素的灰度更高,則提升中心像素的灰度;反之降低中心像素的灰度,從而實現圖像銳化操作。

在實現過程中, Laplacian 算子通過對鄰域中心像素的四方向或八方向求梯度,再將梯度相加起來判斷中心像素灰度與鄰域內其他像素灰度的關係,最後通過梯度運算的結果對像素灰度進行調整。

Laplacian 算子分為四鄰域和八鄰域,四鄰域是對鄰域中心像素的四方向求梯度,八鄰域是對八方向求梯度。

四鄰域模板如下:

\[H = \left[ \begin{matrix} 0 & -1 & 0\\ -1 & 4 & -1\\ 0 & -1 & 0\\ \end{matrix} \right] \]

八鄰域模板如下:

\[H = \left[ \begin{matrix} -1 & -1 & -1\\ -1 & 4 & -1\\ -1 & -1 & -1\\ \end{matrix} \right] \]

通過模板可以發現,當鄰域內像素灰度相同時,模板的卷積運算結果為0;當中心像素灰度高於鄰域內其他像素的平均灰度時,模板的卷積運算結果為正數;當中心像素的灰度低於鄰域內其他像素的平均灰度時,模板的卷積為負數。對卷積運算的結果用適當的衰弱因子處理並加在原中心像素上,就可以實現圖像的銳化處理。

在 OpenCV 中, Laplacian 算子被封裝在 Laplacian() 函數中,其主要是利用Sobel算子的運算,通過加上 Sobel 算子運算出的圖像 x 方向和 y 方向上的導數,得到輸入圖像的圖像銳化結果。

import cv2 as cv
import matplotlib.pyplot as plt

# 讀取圖像
img = cv.imread('maliao.jpg', cv.COLOR_BGR2GRAY)
rgb_img = cv.cvtColor(img, cv.COLOR_BGR2RGB)

# 灰度化處理圖像
grayImage = cv.cvtColor(img, cv.COLOR_BGR2GRAY)

# Laplacian
dst = cv.Laplacian(grayImage, cv.CV_16S, ksize = 3)
Laplacian = cv.convertScaleAbs(dst)

# 用來正常显示中文標籤
plt.rcParams['font.sans-serif'] = ['SimHei']

# 显示圖形
titles = ['原始圖像', 'Laplacian 算子']
images = [rgb_img, Laplacian]

for i in range(2):
    plt.subplot(1, 2, i + 1), plt.imshow(images[i], 'gray')
    plt.title(titles[i])
    plt.xticks([]), plt.yticks([])
plt.show()

最後

邊緣檢測算法主要是基於圖像強度的一階和二階導數,但導數通常對噪聲很敏感,因此需要採用濾波器來過濾噪聲,並調用圖像增強或閾值化算法進行處理,最後再進行邊緣檢測。

最後我先使用高斯濾波去噪之後,再進行邊緣檢測:

import cv2 as cv
import numpy as np
import matplotlib.pyplot as plt

# 讀取圖像
img = cv.imread('maliao.jpg')
rgb_img = cv.cvtColor(img, cv.COLOR_BGR2RGB)

# 灰度化處理圖像
gray_image = cv.cvtColor(img, cv.COLOR_BGR2GRAY)

# 高斯濾波
gaussian_blur = cv.GaussianBlur(gray_image, (3, 3), 0)

# Roberts 算子
kernelx = np.array([[-1, 0], [0, 1]], dtype = int)
kernely = np.array([[0, -1], [1, 0]], dtype = int)
x = cv.filter2D(gaussian_blur, cv.CV_16S, kernelx)
y = cv.filter2D(gaussian_blur, cv.CV_16S, kernely)
absX = cv.convertScaleAbs(x)
absY = cv.convertScaleAbs(y)
Roberts = cv.addWeighted(absX, 0.5, absY, 0.5, 0)

# Prewitt 算子
kernelx = np.array([[1, 1, 1], [0, 0, 0], [-1, -1, -1]], dtype=int)
kernely = np.array([[-1, 0, 1], [-1, 0, 1], [-1, 0, 1]], dtype=int)
x = cv.filter2D(gaussian_blur, cv.CV_16S, kernelx)
y = cv.filter2D(gaussian_blur, cv.CV_16S, kernely)
absX = cv.convertScaleAbs(x)
absY = cv.convertScaleAbs(y)
Prewitt = cv.addWeighted(absX, 0.5, absY, 0.5, 0)

# Sobel 算子
x = cv.Sobel(gaussian_blur, cv.CV_16S, 1, 0)
y = cv.Sobel(gaussian_blur, cv.CV_16S, 0, 1)
absX = cv.convertScaleAbs(x)
absY = cv.convertScaleAbs(y)
Sobel = cv.addWeighted(absX, 0.5, absY, 0.5, 0)

# 拉普拉斯算法
dst = cv.Laplacian(gaussian_blur, cv.CV_16S, ksize = 3)
Laplacian = cv.convertScaleAbs(dst)

# 展示圖像
titles = ['Source Image', 'Gaussian Image', 'Roberts Image',
          'Prewitt Image','Sobel Image', 'Laplacian Image']
images = [rgb_img, gaussian_blur, Roberts, Prewitt, Sobel, Laplacian]
for i in np.arange(6):
   plt.subplot(2, 3, i+1), plt.imshow(images[i], 'gray')
   plt.title(titles[i])
   plt.xticks([]), plt.yticks([])
plt.show()

示例代碼

如果有需要獲取源碼的同學可以在公眾號回復「OpenCV」進行獲取。

參考

https://blog.csdn.net/Eastmount/article/details/89001702

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

南投搬家前需注意的眉眉角角,別等搬了再說!

新北清潔公司,居家、辦公、裝潢細清專業服務