跳到主要內容

.NET Core前後端分離快速開發框架(Core.3.0+AntdVue)

.NET Core前後端分離快速開發框架(Core.3.0+AntdVue)


目錄

































引言


時間真快,轉眼今年又要過去了。回想今年,依次開源發布了Colder.Fx.Net.AdminLTE(254Star)Colder.Fx.Core.AdminLTE(335Star)DotNettySocket(82Star)IdHelper(47Star),這些框架及組件都是本着以實際出發,實事求是的態度,力求提高開發效率(我自己都是第一個使用者),目前來看反響不錯。但是隨着前端和後端技術的不斷變革,尤其是前端,目前大環境已經是前後端完全分離為主的開發模式,在這樣的大環境和必然趨勢之下,傳統的MVC就顯得有些落伍了。在這樣的背景下,一款前後端分離的.NET開發框架就顯得尤為必要,由此便定了框架的升級目標:前後端分離


首先後端技術的選擇,從目前的數據來看,.NET Core的發展遠遠快於.NET Framework,最簡單的分析就是Colder.Fx.Core.AdminLTE發布比Colder.Fx.Net.AdminLTE晚,但是星星卻後來居上而且比前者多30%,並且這個差距在不斷擴大,由點及面的分析可以看出我們廣大.NET開發人員學習的熱情和积極向上的態度,並不是某些人所認為的那麼不堪(走自己的路,讓別人說去吧)。大環境上微軟积極擁抱開源,大力發展.NET Core, 可以說前途一片光明。因此後端決定採用 .NET Core3.0 ,不再浪費精力去支持.NET Framework。


然後是前端技術選擇,首選是三大js框架選擇,也是從實際出發,Vue相對其它而言更加容易上手,並且功能也毫不遜色,深得各種大小公司喜歡,如果偏要說缺點的話,那就是對TS支持不行,但是即將發布Vue3.0肯定會改變這一缺陷。選擇了Vue之後,然後就是UI框架的選擇了,這裏的選擇更多了,我選擇了Ant Design Vue,理由便是簡潔方便,十分符合我的設計理念。


技術選型完畢之後便進入研發,由於鄙人前端比較菜,因此需要從頭學Vue2.x全家桶,從開始到現在差不多經歷3個月,在預期之內。其實學習並使用前端的Vue2.x全家桶並不難,還是比較容易上手的,所以在此給沒有前後端分離開發經驗的老哥打一記預防針,不要退縮,要知難而上,學習永無止境。


某些老哥可能比較直接粗暴,嫌我BBB嘮叨,下面直接上地址
代碼(GitHub):
文檔(GitHub):
代碼(碼雲鏡像):
文檔(碼雲鏡像):
在線預覽地址
由於服務器是阿里雲的86服務器,帶寬1M小水管,因此將前端部署到碼雲上了,在此多謝碼雲,後端部署在阿里雲86服務器CentOS7上。整個技術棧使用.NET Core + PostggreSQL+ Ant Design Vue + CentOS7+Nginx+Dokcer+jenkins,囊括了從快速開發到自動化部署一條龍,開源免費並具有高性能、高移植性、高拓展性(小公司創業選型+個人接單利器


簡介


本框架為.NET Core3.0+Ant Design Vue版


本框架旨在極大的提高開發效率


使用技術棧:
後端:採用.NET Core平台,ASP.NET Core3.0,C#語言(使用反射等高級技術),Entity FrameworkCore(數據庫ORM框架)。
使用數據倉儲模式,抽象化數據庫操作(CRUD等)、支持事務處理以及分佈式事務處理(跨庫)
支持數據庫讀寫分離、分庫分表及事務(僅支持單表操作,不支持多表) 全面採用Autofac作為IOC容器,面向接口編程,全面解耦
集成多種工具類庫以及操作拓展
數據庫:支持SqlServer,PostgreSQL,MySQL,Oracle(框架使用簡單工廠,工廠方法,抽象工廠,可輕鬆更換數據庫),Redis作為分佈式緩存
前端:Vue2.x全家桶+Ant Design Vue,其中集成常用組件,力求方便項目開發。


具體技術實施:
項目採用前後端完全分離模式,並採用嚴格分層模式,極大的增加聚合度,降低耦合度,
提高代碼的健壯性,可維護性。
前後端通過JWT進行身份驗證,通過數據接口操作數據,統一使用JSON作為數據格式,並使用默認接口簽名算法保證接口的安全性。


功能架構部分詳解:
快速開發:此功能為框架的核心,通過選擇數據庫中的表,就能自動生成對應的實體層、業務邏輯層、控制器、前端頁面Vue文件,無需編寫代碼即可生成基本的CRUD操作。
接口密鑰管理:管理接口的密鑰,若開啟接口簽名的規則,則前端需要通過給接口簽名才能夠正常訪問後台接口。
權限管理:使用基本的RBAC權限控制,支持操作權限、接口權限以及數據權限


框架主要功能及特色如下















































































功能 詳細描述
用戶登錄 用戶登錄、密碼修改
系統用戶管理 系統用戶管理
角1色管理 角色管理
部門管理 部門管理、天然多級
權限管理 使用RBAC權限體系,基於角色的權限管理,支持菜單權限、操作權限(按鈕權限)、接口權限、數據權限
系統日誌 支持多彩控制台、文件、數據庫和ElasticSearch記錄日誌,框架全局異常自動捕捉,多級別記錄
快速開發 通過數據庫直接生成實體層、業務邏輯層、控制器層以及前端頁面Vue代碼,無需編碼即可實現CURD
數據庫操作封裝 使用基於EF的倉儲模式、封裝常用的CURD,支持單庫事物和分佈式事物
多數據庫支持 使用基於EF的倉儲模式,支持各大主流關係型數據庫(SQLServer、MySQL、PostgreSQL和Oracle)
超強移植性 使用抽象工廠封裝數據庫操作層,切換數據庫0代碼修改
支持軟刪除 一鍵切換刪除模式,支持物理刪除和軟刪除,對業務操作透明
緩存支持 支持系統自帶緩存和Redis緩存、封裝操作接口、簡單易用
前後端完全分離 前端使用Vue2.x全家桶+Ant Design Vue,界面簡潔美觀,組件化開發
集成JWT驗證 框架使用JWT作為身份驗證,擺脫Cookie苦海,分佈式拓展毫無壓力
集成對外接口簽名算法 框架對外接口可以開啟超強嚴格簽名校驗(防抵賴、防偽造、防重複調用),保障系統安全性
頁面響應式 前端為單頁應用,無iframe,各大主流瀏覽器支持友好
拓展 其它各種幫助類庫及插件

其相關版本請看下錶:










































.NET版本 前端UI 地址
Core3.0 Ant Design Vue
Core2.2 AdminLTE
.NET4.72 AdminLTE
.NET4.52 Easyui
Core2.1 Easyui
.NET4.0 Easyui

後台效果展示如下:


環境搭建


開發環境要求:


操作系統:Windows 10
後端開發工具:Visual Studio 2019+
前端開發工具:Visual Studio Code,安裝nodejs,yarn
SDK:安裝.NET Core SKD 3.0 及以上
數據庫:SQLServer2008 R2及以上


基礎數據庫構建:



  • 數據庫創建
    目錄"/docs/初始化文件"中有所需的數據庫資料

    先手動創建數據庫,然後執行對應的SQL腳本即可


  • 連接字符串配置
    打開src目錄下Colder.Admin.AntdVue的解決方案,如下圖




如下圖所示依次展開05.Coldairarrow.Api/appsettings.json,配置數據庫連接字符串,name不用修改,connectionString改為上述創建的數據庫(若不清楚數據庫連接字符串請自行百度搜索教程)


數據庫設計規範


由於本框架支持自動生成代碼的核心功能,此功能是根據數據庫的表結構來生成代碼的
因此規定每張表都有一個主鍵,列名為Id,類型為字符串,實際添加數據時默認使用SnowflakeId(雪花Id,Twitter設計的分佈式趨勢自增Id,若不清楚請自行百度相關資料),表中的每個列都需要有描述信息(建議這樣操作,若不按照這個標準則需要一些額外的改動才能夠成功運行)。每張表都需要Id、CreateTime、CreatorId、CreatorRealName這幾個必帶字段



運行


後端:打開解決方案=>還原nuget包=>配置數據庫=>運行(05.Coldairarrow.Api設為啟動項目)
後台成功運行後會自動打開swagger

前端: 確保已安裝nodejsyarn
用VS Code 打開文件夾src\Coldairarrow.Web

輸入命令:yarn
輸入命令:yarn run serve
成功運行后即可打開登錄頁面

輸入賬號:Admin,密碼:123456進入後台主頁


使用教程


全局配置


在01.Coldairarrow.Util中的GlobalSwitch類中,設置了各個參數,其中RunModelDatabaseType需要重點關注一下,其它參數請看註釋。


快速開發


此功能為本框架的核心功能,能夠自動生產完整的可運行代碼,具體使用如下:



  • 配置數據源


首選需要有數據庫源,因為代碼生成是根據數據庫表來生成的。
菜單:開發=>數據庫連接

若列表中沒有目標數據源,則添加數據庫連接

數據連接名、連接字符串、數據庫類型即可。添加完成后即可看到連接字符串信息。



  • 生成代碼


有了數據庫連接之後,即可進行代碼生成。
菜單:開發=>代碼生成



選擇數據庫,然後勾選需要生成代碼的數據庫表,點擊生成代碼會彈出生成選項(這裏演示勾選 Base_BuildTest,其餘表全是系統基礎表,不要勾選,否則會被覆蓋,導致異常,請勾選自己的業務表進行生成):



生成選項中可以選擇需要生成的類型,默認生成全部:實體層、業務層、接口層(即控制器)和頁面(Vue前端頁面代碼)。
生成區域請輸入業務模塊名(例如系統叫Base_Manage),請按具體業務填入(必填)
這裏示例填寫TestManage,點擊生成按鈕,即可完成代碼生成。生成后的代碼在項目解決方案中,將代碼文件包括進入項目


默認生成后的文件會被自動包括到解決方案中,若沒有則需要點擊显示所有文件按鈕,即可看到生成后的新文件


生成的實體層、業務邏輯層、控制器層代碼:


前端生成的代碼:


後端代碼添加后需要重新編譯下(F7),編譯后好可以看到有新的接口

前端生成代碼後會自動保存並編譯(別的文件修改保存也會自動編譯,畢竟編譯一次挺慢的),不放心可以Ctrl+C停止,然後再yarn run serve重新運行


代碼生成完畢,但是要展示到菜單上需要進行配置,並且所有業務菜單都是動態的(權限控制)
打開菜單:系統管理=>權限管理=>新建


菜單名:即需要显示的菜單名
上級菜單:菜單是多級樹狀的,可以放在某個菜單下面
類型:可以選擇菜單或頁面,這裡是具體的頁面,所以選頁面
路徑:頁面的路徑,菜單可以不配置,這裏配置為/TestManage/Base_BuildTest/List,這裏設置規則為:views文件夾為根路徑(即"/"),向下展開依次為/TestManage/Base_BuildTest/List,最後真正的列表頁為List.vue文件,表單頁為EditForm.vue文件
是否需要權限:若為"否",則此頁面不限制權限,即所有人都能看
圖標:菜單显示圖標,具體到開發=>圖標選擇頁進行選擇
排序:若需要需要對菜單進行排序則設置,默認0,類型為int
頁面權限:頁面擁有的權限(權限值唯一,作為操作權限即接口權限的依據),詳見權限管理


確認保存,然後刷新整個頁面(F5),即可看到全新生成的菜單"生成測試"



整個代碼生成過程,無需編寫代碼即可完成一張表的CRUD,當然需要根據具體業務中進行相應的修改,本次示例中字段比較少,但是當一張表的字段很多時,那麼此功能能夠將開發效率提高几個檔次。


管理員登錄



默認超級管理員賬號為:Admin
密碼為:123456


系統用戶管理


管理系統登錄的用戶
菜單:系統=>用戶管理
點擊右側設置權限


系統角色管理


管理系統角色,角色是權限的載體,合理分配角色有利於權限管理
菜單:系統=>角色管理
操作中可以設置角色的權限,詳情見 模塊


權限管理


一般情況下,後台管理系統多少會涉及權限管理,因此本框架提供了一個靈活、高效、簡潔的權限管理系統。


首先,權限分為兩種,即操作權限數據權限,其中操作權限主要包括菜單權限和按鈕權限,在角色編輯表單中,給角色勾選需要的權限即可,用戶可以分配多個角色,繼承所有角色的權限。

如上圖,按需勾選,有人會疑問為什麼只有增、改和刪的權限而沒有查的權限,其實這裏考慮到了當勾選"用戶管理"時,就已經默認擁有"查"的權限了,這裏再設置"查"權限豈不是多此一舉,可以根據實際業務需求添加諸如申請、審核等權限,靈活應用。
這裏的樹狀是和菜單一一對應的,勾選哪些菜單就擁有哪些菜單


下面介紹下最常用的按鈕權限


如上圖,在需要控制權限的按鈕使用v-if="hasPerm('Base_User.Add')",表示只有當用戶擁有權限值Base_User.Add才显示此按鈕,權限值就是權限表單中配置的權限值


這裏的按鈕級權限控制只能夠在前端控制操作入口,若系統對安全性要求較高,則需要控制接口權限


如上圖,在需要權限控制的接口加上ApiPermission特性即可,參數也為權限值,只有擁有此權限才能訪問此接口


數據權限比較複雜,若採用純SQL方式,那麼會更加複雜,本框架全程採用EF作為ORM框架,通過對IQueryable< T >進行過濾,即可完成數據權限控制,詳細使用方式見用戶管理


更詳細的使用方式,請參考源代碼中的用戶管理模塊(菜單權限、操作權限、數據權限、聯表查詢、業務層AOP等使用方式均可參考此模塊)


接口秘鑰管理


作為對外接口簽名的AppId和AppSecret管理
菜單:系統=>接口秘鑰管理


系統日誌


菜單:系統=>系統日誌


單庫事務


使用方式如下:


BaseBusiness<Base_UnitTest> _baseBus  = new BaseBusiness<Base_UnitTest>();
/*RunTransaction傳入執行具體數據庫操作的Action,操作中若出現異常會自動回滾事務,業務只需根據返回的transActionRes進行處理,返回類型為元組(bool Success, Exception ex),Success表示事務是否成功,ex為事務失敗異常信息*/
var transActionRes = _baseBus.RunTransaction(() =>
{
var newData = _newData.DeepClone();
newData.Id = Guid.NewGuid().ToString();
newData.UserId = IdHelper.GetId();
newData.UserName = IdHelper.GetId();
_baseBus.Insert(_newData);
_baseBus.Insert(newData);
});

跨庫事務


使用方式如下:


//第一個數據庫
IRepository _bus1 = DbFactory.GetRepository();
//另一個數據庫
IRepository _bus2 = DbFactory.GetRepository("BaseDb_Test");
_bus1.DeleteAll<Base_UnitTest>();
_bus2.DeleteAll<Base_UnitTest>();
Base_UnitTest data1 = new Base_UnitTest
{
Id = Guid.NewGuid().ToString(),
UserId = "1",
UserName = Guid.NewGuid().ToString()
};
Base_UnitTest data2 = new Base_UnitTest
{
Id = data1.Id,
UserId = "1",
UserName = Guid.NewGuid().ToString()
};
Base_UnitTest data3 = new Base_UnitTest
{
Id = Guid.NewGuid().ToString(),
UserId = "2",
UserName = Guid.NewGuid().ToString()
};

new Action(() =>
{
//創建並執行事務,使用方式與單庫一致
var succcess = DistributedTransactionFactory.GetDistributedTransaction(_bus1, _bus2)
.RunTransaction(() =>
{
_bus1.ExecuteSql("insert into Base_UnitTest(Id) values('10') ");
_bus1.Insert(data1);
_bus1.Insert(data2);
_bus2.Insert(data1);
_bus2.Insert(data3);
});
Assert.AreEqual(succcess.Success, false);
Assert.AreEqual(_bus1.GetIQueryable<Base_UnitTest>().Count(), 0);
Assert.AreEqual(_bus2.GetIQueryable<Base_UnitTest>().Count(), 0);
})();

讀寫分離分庫分表


本框架支持數據庫讀寫分離分庫分表(即Sharding),並且支持主流關係型數據庫(SQLServer、Oracle、MySQL、PostgreSQL),理論上只要EF支持那麼本框架支持。
由於技術原因以及結合實際情況,目前本框架僅支持單表的Sharding,即支持單表的CRUD、分頁、統計(數量、最大值、最小值、平均值),支持跨庫(表分散在不同的數據庫中,不同類型數據庫也支持)。具體如何使用如下:



  • Sharding配置
    首先、要進行分庫分表操作,那麼必要的配置必不可少。配置代碼如下:


ShardingConfigBootstrapper.Bootstrap()
//添加數據源
.AddDataSource("BaseDb", DatabaseType.SqlServer, dbBuilder =>
{
//添加物理數據庫
dbBuilder.AddPhsicDb("BaseDb", ReadWriteType.ReadAndWrite);
})
//添加抽象數據庫
.AddAbsDb("BaseDb", absTableBuilder =>
{
//添加抽象數據表
absTableBuilder.AddAbsTable("Base_UnitTest", tableBuilder =>
{
//添加物理數據表
tableBuilder.AddPhsicTable("Base_UnitTest_0", "BaseDb");
tableBuilder.AddPhsicTable("Base_UnitTest_1", "BaseDb");
tableBuilder.AddPhsicTable("Base_UnitTest_2", "BaseDb");
}, new ModShardingRule("Base_UnitTest", "Id", 3));
});

上述代碼中完成了Sharding的配置:
ShardingConfigBootstrapper.Bootstrap()在一個項目中只能執行一次,所以建議放到Application_Start中(ASP.NET Core中的Startup)
AddDataSource是指添加數據源,數據源可以看做抽象數據庫,一個數據源包含了一組同類型的物理數據庫,即實際的數據庫。一個數據源至少包含一個物理數據庫,多個物理數據庫需要開啟主從複製或主主複製,通過ReadWriteType(寫、讀、寫和讀)參數來指定數據庫的操作類型,通常將寫庫作為主庫,讀庫作為從庫。同一個數據源中的物理數據庫類型相同,表結構也相同。
配置好數據源后就可以通過AddAbsDb來添加抽象數據庫,抽象數據庫中需要添加抽象數據表。如上抽象表Base_UnitTest對應的物理表就是Base_UnitTest_0、Base_UnitTest_1與Base_UnitTest_2,並且這三張表都屬於數據源BaseDb。分表配置當然需要分表規則(即通過一種規則找到具體數據在哪張表中)。
上述代碼中使用了最簡單的取模分片規則
源碼如下:

可以看到其使用方式及優缺點。
另外還有一致性HASH分片規則

雪花Id的mod分片規則


上述的分片規則各有優劣,都實現IShardingRule接口,實際上只需要實現FindTable方法即可實現自定義分片規則。
實際使用中個人推薦使用雪花Id的mod分片規,這也是為什麼前面數據庫設計規範中默認使用雪花Id作為數據庫主鍵的原因(PS,之前版本使用GUID作為主鍵被各種嫌棄,這次看你們怎麼說)



  • 使用方式
    配置完成,下面開始使用,使用方式非常簡單,與平常使用基本一致
    首先獲取分片倉儲接口IShardingRepository


IShardingRepository _db = DbFactory.GetRepository().ToSharding();

然後即可進行數據操作:


Base_UnitTest _newData  = new Base_UnitTest
{
Id = Guid.NewGuid().ToString(),
UserId = "Admin",
UserName = "超級管理員",
Age = 22
};
List<Base_UnitTest> _insertList = new List<Base_UnitTest>
{
new Base_UnitTest
{
Id = Guid.NewGuid().ToString(),
UserId = "Admin1",
UserName = "超級管理員1",
Age = 22
},
new Base_UnitTest
{
Id = Guid.NewGuid().ToString(),
UserId = "Admin2",
UserName = "超級管理員2",
Age = 22
}
};
//添加單條數據
_db.Insert(_newData);
//添加多條數據
_db.Insert(_insertList);
//清空表
_db.DeleteAll<Base_UnitTest>();
//刪除單條數據
_db.Delete(_newData);
//刪除多條數據
_db.Delete(_insertList);
//刪除指定數據
_db.Delete<Base_UnitTest>(x => x.UserId == "Admin2");
//更新單條數據
_db.Update(_newData);
//更新多條數據
_db.Update(_insertList);
//更新單條數據指定屬性
_db.UpdateAny(_newData, new List<string> { "UserName", "Age" });
//更新多條數據指定屬性
_db.UpdateAny(_insertList, new List<string> { "UserName", "Age" });
//更新指定條件數據
_db.UpdateWhere<Base_UnitTest>(x => x.UserId == "Admin", x =>
{
x.UserId = "Admin2";
});
//GetList獲取表的所有數據
var list=_db.GetList<Base_UnitTest>();
//GetIQPagination獲取分頁后的數據
var list=_db.GetIShardingQueryable<Base_UnitTest>().GetPagination(pagination);
//Max
var max=_db.GetIShardingQueryable<Base_UnitTest>().Max(x => x.Age);
//Min
var min=_db.GetIShardingQueryable<Base_UnitTest>().Min(x => x.Age);
//Average
var min=_db.GetIShardingQueryable<Base_UnitTest>().Average(x => x.Age);
//Count
var min=_db.GetIShardingQueryable<Base_UnitTest>().Count();
//事務,使用方式與普通事務一致
bool succcess = _db.RunTransaction(() =>
{
_db.Insert(_newData);
var newData2 = _newData.DeepClone();
_db.Insert(newData2);
}).Success;
Assert.AreEqual(succcess, false);

上述操作中表面上是操作Base_UnitTest表,實際上卻在按照一定規則使用Base_UnitTest_0~2三張表,使分片對業務操作透明,極大提高開發效率
具體使用方式請參考單元測試源碼:
"\src\Coldairarrow.UnitTests\DataRepository\ShardingTest.cs"


常見疑問


如何進行聯表查詢


框架使用EF+LINQ進行聯表操作,核心在於對IQueryable< T >的使用,另可網上搜EF+LINQ的相關教程。


示例如下:
Base_User表左連接Base_Department表獲取DepartmentName屬性


//定義數據模型類
public class Base_UserTestDTO : Base_User
{
public string DepartmentName { get; set; }
}

//即BaseBusiness中的Service
var db = DbFactory.GetRepository();
Expression<Func<Base_User, Base_Department, Base_UserTestDTO>> select = (a, b) => new Base_UserTestDTO
{
DepartmentName = b.Name
};
select = select.BuildExtendSelectExpre();
var q = from a in db.GetIQueryable<Base_User>().AsExpandable()
join b in db.GetIQueryable<Base_Department>() on a.DepartmentId equals b.Id into ab
from b in ab.DefaultIfEmpty()
select @select.Invoke(a, b);
//篩選
var where = LinqHelper.True<Base_UserTestDTO>();
where = where.And(x => x.UserName == "Admin");

//篩選並獲取分頁數據
var list = q.Where(where).GetPagination(new Pagination()).ToList();

源碼可參考Base_UserBusiness.GetDataList


如何切換數據庫類型


在01.Coldairarrow.Util項目中的GlobalSwitch,將DatabaseType改為需要的即可,對應的數據庫連接字符串當然也要改為對應數據庫的


如何使用多個數據庫


在具體的Business類中重寫父類BaseBusiness的構造函數即可,按照自己的需求重寫對應的構造函數,同時需要確保數據庫連接字符串已添加




若需要同時使用多個數據庫,或者需要多線程操作數據庫,需要使用


結語


歡迎使用本框架,若覺得不錯,請比心



Github歡迎星星:


博客園歡迎點贊:


QQ群2:579202910
個人QQ:862520575(歡迎技術支持及商務合作,提供.NET Core + Linux + Nginx+ jenkins + git整套持續集成快速開發平台


本人將會對這個快速開發框架不斷完善與維護,希望能夠幫助到各位


若遇到任何問題或需要技術支持,請聯繫我。


------學習永無止境,技術永無上限,代碼就是藝術------

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

【其他文章推薦】

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



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



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



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



Orignal From: .NET Core前後端分離快速開發框架(Core.3.0+AntdVue)

留言

這個網誌中的熱門文章

Python 併發總結,多線程,多進程,異步IO

1 測量函數運行時間 import time def profile(func): def wrapper(*args, ** kwargs): import time start = time.time() func( *args, ** kwargs) end = time.time() print ' COST: {} ' .format(end - start) return wrapper @profile def fib(n): if n<= 2 : return 1 return fib(n-1) + fib(n-2 ) fib( 35 )   2 啟動多個線程,並等待完成   2.1 使用threading.enumerate() import threading for i in range(2 ): t = threading.Thread(target=fib, args=(35 ,)) t.start() main_thread = threading.currentThread() for t in threading.enumerate(): if t is main_thread: continue t.join()   2.2 先保存啟動的線程 threads = [] for i in range(5 ): t = Thread(target=foo, args= (i,)) threads.append(t) t.start() for t in threads: t.join()   3 使用信號量,限制同時能有幾個線程訪問臨界區 from threading import Semaphore import time sema = Semaphor...

高雄十大包子名店出爐

, 圖文:吳恩文 高雄包子大賽落幕了,我只能就我個人意見, 介紹一下前十名這些包子,但是不能代表其他四位評審的意見,雖然身為評審長,我通常不會第一個表示意見,以免影響其他評審, 我主要工作是負責發問。   這次參賽的素包子很少,而且都不夠細致,又偏油,我不愛, 但是第一名的甜芝麻包-熔岩黑金包,竟然是素食得名- 漢來蔬食巨蛋店。   這包子賣相太好,竹炭粉的黑色外皮刷上金粉,一上桌,眾人驚呼, 搶拍照,內餡是芝麻餡,混一點花生醬增稠,加入白糖芝麻油, 熔岩爆漿的程度剛剛好,我一直以為芝麻要配豬油才行、 但是選到好的黑芝麻油一樣不減香醇, 當下有二位評審就想宅配回家。   尤其特別的是,黑芝麻餡室溫易化,師傅必須要輪班躲在冷藏室內, 穿著大外套才能包,一天包不了多少,我笑說,漢來美食,集團餐廳那麼多,實力雄厚,根本是「 奧運選手報名參加村裡運動會」嘛,其他都是小包子店啊, 但是沒辦法,顯然大家都覺得它好看又好吃, 目前限定漢來蔬食高雄巨蛋店,二顆88元,可以冷凍宅配, 但是要排一陣子,因為供不應求,聽說,四月份, 台北sogo店開始會賣。   第二名的包子,左營寬來順早餐店,顯然平易近人的多,一顆肉包, 十塊錢,是所有參賽者中最便宜的,當然,個頭也小, 它的包子皮明顯和其他不同,灰灰的老麵,薄但紮實有嚼勁, 肉餡新鮮帶汁,因為打了些水,味道極其簡單,就是蔥薑,塩, 香油,薑味尤其明顯,是老眷村的味道, 而特別的是老闆娘是台灣本省人, 當年完全是依據眷村老兵的口味一步一步調整而來,沒有加什麼糖、 五香粉,胡椒粉,油蔥酥。就是蔥薑豬肉和老麵香,能得名, 應該是它的平實無華,鮮美簡單,打動人心。   這是標準的心靈美食,可以撫慰人心,得名之前,寛來順已經天天排隊,現在,恐怕要排更久了, 建議大家六七點早點上門。   第三名,「專十一」很神奇,我記得比賽最後, 大家連吃了幾家不能引起共鳴的包子,有些累,到了專十一, 就坐著等包子,其他評審一吃,就催我趕快試,我一吃, 也醒了大半。   它的包子皮厚薄適中,但是高筋麵粉高些,老麵加一點點酵母, 我心中,它的皮屬一屬二,至於餡又多又好吃,蛋黃還是切丁拌入, 不是整顆放,吃起來「美味、均衡、飽滿」。一顆二十元。   老闆是陸軍專科十一期畢業取名專十一,...

韋伯連續劇終於更新 期待第一季順利完結

  地球天文學界的跳票大王詹姆斯·韋伯空間望遠鏡 (James Webb Space Telescope,縮寫為 JWST)自 1996 年以來斷斷續續不按劇本演出的連續劇終於讓焦慮的觀眾們又等到了一次更新:五層遮陽罩測試順利完成。 裝配完成的韋伯望遠鏡與好夥伴遮陽罩同框啦。Credit: NASA   嚴格的測試是任何空間任務順利成功的重中之重。遮陽罩,這個韋伯望遠鏡異常重要的親密夥伴,要是無法正常運轉的話,韋伯的這一季天文界連續劇說不準就要一直拖更了。   詹姆斯·韋伯空間望遠鏡是歷史上造出的最先進的空間望遠鏡。它不僅是一架紅外望遠鏡,還具有特別高的靈敏度。但想要達到辣么高的靈敏度來研究系外行星和遙遠的宇宙童年,韋伯童鞋必須非常"冷靜",體溫升高的話,靈敏度會大大折損。這個時候,遮陽罩就要大顯身手啦。   遮陽罩在韋伯的設計中至關重要。韋伯望遠鏡會被發射到拉格朗日 L2 點,運行軌道很高,遠離太陽、地球與月球。太陽是韋伯的主要熱量干擾的來源,其次是地球與月球。遮陽罩會有效阻斷來自這三大熱源的能量並保護韋伯維持在工作溫度正常運轉。這個工作溫度指的是零下 220 攝氏度(-370 華氏度;50 開爾文)。 上圖中我們可以看出,韋伯望遠鏡的配置大致可分為兩部分:紅色較熱的一面溫度為 85 攝氏度,藍色較冷的一面溫度達到零下 233 攝氏度。紅色的這部分中,儀器包括太陽能板、通信設備、計算機、以及轉向裝置。藍色部分的主要裝置包括鏡面、探測器、濾光片等。Credit: STSci.   遮陽罩的那一部分和望遠鏡的鏡面這部分可以產生非常極端的溫差。遮陽的這面溫度可以達到 110 攝氏度,足以煮熟雞蛋,而背陰處的部分溫度極低,足以凍結氧氣。   工程師們剛剛完成了五層遮陽罩的測試,按照韋伯在 L2 時的運行狀態安裝了遮陽罩。L2 距離地球約 160 萬公里。NASA 表示這些測試使用了航天器的自帶系統來展開遮陽罩,測試目前都已成功完成。韋伯望遠鏡遮陽罩負責人 James Cooper 介紹說這是遮陽罩"第一次在望遠鏡系統的电子設備的控制下展開。儘管這個任務非常艱巨,難度高,但測試順利完成,遮陽罩展開時的狀態非常驚艷"。   遮陽罩由五層 Kapton 製成。Kapton 是一種聚酰亞胺薄膜材料, 耐高溫絕...