【asp.net core 系列】8 實戰之 利用 EF Core 完成數據操作層的實現

0. 前言

通過前兩篇,我們創建了一個項目,並規定了一個基本的數據層訪問接口。這一篇,我們將以EF Core為例演示一下數據層訪問接口如何實現,以及實現中需要注意的地方。

1. 添加EF Core

先在數據層實現層引入 EF Core:

cd Domain.Implements
dotnet add package Microsoft.EntityFrameworkCore

當前項目以SqlLite為例,所以再添加一個SqlLite數據庫驅動:

dotnet add package Microsoft.EntityFrameworkCore.SQLite

刪除 Domain.Implements 里默認的Class1.cs 文件,然後添加Insfrastructure目錄,創建一個 DefaultContext:

using Microsoft.EntityFrameworkCore;

namespace Domain.Implements.Insfrastructure
{
    public class DefaultContext : DbContext
    {
        private string ConnectStr { get; }
        public DefaultContext(string connectStr)
        {
            ConnectStr = connectStr;
        }

        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        {
            optionsBuilder.UseSqlite(ConnectStr);//如果需要別的數據庫,在這裏進行修改
        }
    }
}

2. EF Core 批量加載模型

通常情況下,在使用ORM的時候,我們不希望過度的使用特性來標註實體類。因為如果後期需要變更ORM或者出現其他變動的時候,使用特性來標註實體類的話,會導致遷移變得複雜。而且大部分ORM框架的特性都依賴於框架本身,並非是統一的特性結構,這樣就會造成一個後果:本來應該是對調用方隱藏的實現就會被公開,而且在項目引用關係中容易出現循環引用。

所以,我在開發中會尋找是否支持配置類,如果使用配置類或者在ORM框架中設置映射關係,那麼就可以保證數據層的純凈,也能實現對調用方隱藏實現。

EF Core的配置類我們在《C# 數據訪問系列》中關於EF的文章中介紹過,這裏就不做過多介紹了(沒來得及看的小夥伴們不着急,後續會有一個簡單版的介紹)。

通常情況下,配置類我也會放在Domain.Implements項目中。現在我給大家介紹一下如何快速批量加載配置類:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.ApplyConfigurationsFromAssembly(Assembly.GetAssembly(this.GetType()),
		t => t.GetInterfaces().Any(i => t.Name.Contains("IEntityTypeConfiguration")));
}

現在版本的EF Core支持通過Assembly加載配置類,可以指定加載當前上下文類所在的Assembly,然後篩選實現接口中包含IEntityTypeConfiguration的類即可。

3. 使用EF Core實現數據操作

我們已經創建好了一個EF Context,那麼現在就帶領大家一起看一下,如何使用EF來實現 上一篇《「asp.net core」7 實戰之 數據訪問層定義》中介紹的數據訪問接口:

新建一個BaseRepository類,在Domain.Implements項目的Insfrastructure 目錄下:

using Domain.Infrastructure;
using Microsoft.EntityFrameworkCore;

namespace Domain.Implements.Insfrastructure
{
    public abstract class BaseRepository<T> : ISearchRepository<T>, IModifyRepository<T> where T : class
    {
        public DbContext Context { get; }
        protected BaseRepository(DbContext context)
        {
            Context = context;
        }
    }
}

先創建以上內容,這裏給Repository傳參的時候,使用的是EFCore的默認Context類不是我們自己定義的。這是我個人習慣,實際上並沒有其他影響。主要是為了對實現類隱藏具體的EF 上下文實現類。

在實現各接口方法之前,創建如下屬性:

public DbSet<T> Set { get => Context.Set<T>(); }

這是EF操作數據的核心所在。

3.1 實現IModifyRepository接口

先實現修改接口:

public T Insert(T entity)
{   
    return Set.Add(entity).Entity;
}

public void Insert(params T[] entities)
{
    Set.AddRange(entities);
}

public void Insert(IEnumerable<T> entities)
{
    Set.AddRange(entities);
}
public void Update(T entity)
{
    Set.Update(entity);
}

public void Update(params T[] entities)
{
    Set.UpdateRange(entities);
}

public void Delete(T entity)
{
    Set.Remove(entity);
}

public void Delete(params T[] entities)
{
    Set.RemoveRange(entities);
}

在修改接口裡,我預留了幾個方法沒有實現,因為這幾個方法使用EF Core自身可以實現,但實現會比較麻煩,所以這裏藉助一個EF Core的插件:

dotnet add package Z.EntityFramework.Plus.EFCore

這是一個免費開源的插件,可以直接使用。在Domain.Implements 中添加后,在BaseRepository 中添加如下引用:

using System.Linq;
using System.Linq.Expressions;

實現方法:

public void Update(Expression<Func<T, bool>> predicate, Expression<Func<T, T>> updator)
{
    Set.Where(predicate).UpdateFromQuery(updator);
}

public void Delete(Expression<Func<T, bool>> predicate)
{
    Set.Where(predicate).DeleteFromQuery();
}

public void DeleteByKey(object key)
{
    Delete(Set.Find(key));
}

public void DeleteByKeys(params object[] keys)
{
    foreach (var k in keys)
    {
        DeleteByKey(k);
    }
}

這裏根據主鍵刪除的方法有個問題,我們無法根據條件進行刪除,實際上如果約定泛型T是BaseEntity的子類,我們可以獲取到主鍵,但是這樣又會引入另一個泛型,為了避免引入多個泛型根據主鍵的刪除就採用了這種方式。

3.2 實現ISearchRepository 接口

獲取數據以及基礎統計接口:

public T Get(object key)
{
    return Set.Find(key);
}

public T Get(Expression<Func<T, bool>> predicate)
{
    return Set.SingleOrDefault(predicate);
}

public int Count()
{
    return Set.Count();
}

public long LongCount()
{
    return Set.LongCount();
}

public int Count(Expression<Func<T, bool>> predicate)
{
    return Set.Count(predicate);
}

public long LongCount(Expression<Func<T, bool>> predicate)
{
    return Set.LongCount(predicate);
}

public bool IsExists(Expression<Func<T, bool>> predicate)
{
    return Set.Any(predicate);
}

這裡有一個需要關注的地方,在使用條件查詢單個數據的時候,我使用了SingleOrDefault而不是FirstOrDefault。這是因為我在這裏做了規定,如果使用條件查詢,調用方應該能預期所使用條件是能查詢出最多一條數據的。不過,這裏可以根據實際業務需要修改方法:

  • Single 返回單個數據,如果數據大於1或者等於0,則拋出異常
  • SingleOrDefault 返回單個數據,如果結果集沒有數據,則返回null,如果多於1,則拋出異常
  • First 返回結果集的第一個元素,如果結果集沒有數據,則拋出異常
  • FirstOrDefault 返回結果集的第一個元素,如果沒有元素則返回null

實現查詢方法:

public List<T> Search()
{
    return Query().ToList();
}

public List<T> Search(Expression<Func<T, bool>> predicate)
{
    return Query(predicate).ToList();
}

public IEnumerable<T> Query()
{
    return Set;
}

public IEnumerable<T> Query(Expression<Func<T, bool>> predicate)
{
    return Set.Where(predicate);
}

public List<T> Search<P>(Expression<Func<T, bool>> predicate, Expression<Func<T, P>> order)
{
    return Search(predicate, order, false);
}

public List<T> Search<P>(Expression<Func<T, bool>> predicate, Expression<Func<T, P>> order, bool isDesc)
{
    var source = Set.Where(predicate);
    if (isDesc)
    {
        source = source.OrderByDescending(order);
    }
    else
    {
        source = source.OrderBy(order);
    }
    return source.ToList();
}

這裏我盡量通過調用了參數最多的方法來實現查詢功能,這樣有一個好處,小夥伴們可以想一下哈。當然了,這是我自己覺得這樣會好一點。

實現分頁:

在實現分頁之前,我們知道當時我們定義的分頁參數類的排序字段用的是字符串,而不是lambda表達式,而Linq To EF需要一個Lambda表示才可以進行排序。這裏就有兩種方案,可以自己寫一個方法,實現字符串到Lambda表達式的轉換;第二種就是借用三方庫來實現,正好我們之前引用的EF Core增強插件里有這個功能:

var list = context.Customers.OrderByDescendingDynamic(x => "x.Name").ToList();

這是它給出的示例。

我們可以先依此來寫一份實現方法:

public PageModel<T> Search(PageCondition<T> condition)
{
    var result = new PageModel<T>
    {
        TotalCount = LongCount(condition.Predicate),
        CurrentPage = condition.CurrentPage,
        PerpageSize = condition.PerpageSize,
    };
    var source = Query(condition.Predicate);
    if (condition.Sort.ToUpper().StartsWith("a")) // asc
    {
        source = source.OrderByDynamic(t => $"t.{condition.OrderProperty}");
    }
    else // desc
    {
        source = source.OrderByDescendingDynamic(t => $"t.{condition.OrderProperty}");
    }
    var items = source.Skip((condition.CurrentPage -1)* condition.PerpageSize).Take(condition.PerpageSize);
    result.Items = items.ToList();
    return result;
}

回到第一種方案:

我們需要手動寫一個字符串的處理方法,先在Utils項目創建以下目錄:Extend>Lambda,並在目錄中添加一個ExtLinq類,代碼如下:

using System.Linq;
using System.Linq.Expressions;
using System.Text.RegularExpressions;

namespace Utils.Extend.Lambda
{
    public static class ExtLinq
    {
        public static IQueryable<T> CreateOrderExpression<T>(this IQueryable<T> source, string orderBy, string orderAsc)
        {
            if (string.IsNullOrEmpty(orderBy)|| string.IsNullOrEmpty(orderAsc)) return source;
            var isAsc = orderAsc.ToLower() == "asc";
            var _order = orderBy.Split(',');
            MethodCallExpression resultExp = null;
            foreach (var item in _order)
            {
                var orderPart = item;
                orderPart = Regex.Replace(orderPart, @"\s+", " ");
                var orderArry = orderPart.Split(' ');
                var orderField = orderArry[0];
                if (orderArry.Length == 2)
                {
                    isAsc = orderArry[1].ToUpper() == "ASC";
                }
                var parameter = Expression.Parameter(typeof(T), "t");
                var property = typeof(T).GetProperty(orderField);
                var propertyAccess = Expression.MakeMemberAccess(parameter, property);
                var orderByExp = Expression.Lambda(propertyAccess, parameter);
                resultExp = Expression.Call(typeof(Queryable), isAsc ? "OrderBy" : "OrderByDescending",
                    new[] {typeof(T), property.PropertyType},
                    source.Expression, Expression.Quote(orderByExp));
            }

            return resultExp == null
                ? source
                : source.Provider.CreateQuery<T>(resultExp);
        }
    }
}

暫時不用關心為什麼這樣寫,後續會為大家分析的。

然後回過頭來再實現我們的分頁,先添加Utils 到Domain.Implements項目中

cd ../Domain.Implements # 進入Domain.Implements 項目目錄
dotnet add reference ../Utils
public PageModel<T> Search(PageCondition<T> condition)
{
    var result = new PageModel<T>
    {
        TotalCount = LongCount(condition.Predicate),
        CurrentPage = condition.CurrentPage,
        PerpageSize = condition.PerpageSize,
    };
    var source = Set.Where(condition.Predicate).CreateOrderExpression(condition.OrderProperty, condition.Sort);
    var items = source.Skip((condition.CurrentPage -1)* condition.PerpageSize).Take(condition.PerpageSize);
    result.Items = items.ToList();
    return result;
}

記得添加引用:

using Utils.Extend.Lambda;

在做分頁的時候,因為前台傳入的參數大多都是字符串的排序字段,所以到後端需要進程字符串到字段的處理。這裏的處理利用了C# Expression的一個技術,這裏就不做過多介紹了。後續在.net core高級篇中會有介紹。

4. 總結

到目前為止,看起來我們已經成功實現了利用EF Core為我們達成 數據操作和查詢的目的。但是,別忘了EF Core需要手動調用一個SaveChanges方法。下一篇,我們將為大家介紹如何優雅的執行SaveChanges方法。

這一篇介紹到這裏,雖然說明不是很多,但是這也是我在開發中總結的經驗。

更多內容煩請關注我的博客《高先生小屋》

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

【其他文章推薦】

※別再煩惱如何寫文案,掌握八大原則!

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

網頁設計最專業,超強功能平台可客製化

※產品缺大量曝光嗎?你需要的是一流包裝設計!

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

Python 3.9 beta2 版本發布了,看看這 7 個新的 PEP 都是什麼?

原作:Jake Edge

譯者:豌豆花下貓@Python貓

英文:https://lwn.net/Articles/819853/

隨着 Python 3.9.0b1 的發布,即開發周期中計劃的四個 beta 版本的首個,Python 3.9 的功能已經是完善了。在 10 月發布最終版本之前,還會有許多測試和穩定性方面的工作要做。

(譯註:beta1 版本發佈於 5 月 18 日,作者文章寫於 5 月 20,而到本篇譯文發布時,beta2 剛好在今天即 6 月 9 日發布,這是一個巧合!)

該發布說明中列出了被 3.9 接受的 7 個 Python 增強提案(PEP)。我們研究了其中的一些 PEP,看到有一些更新。現在似乎是一個介紹 Python 3.9 帶來的一些東西的好時機。

1、字符串操作

有時最簡單(表明上的)的事情最困難,或者至少會引起巨大的討論。其中大部分的爭議是關於命名(還能是什麼?),但是給標準字符串對象添加函數,來刪除前綴和後綴,這種想法是毫無爭議的。

是否可以將那些詞綴(前綴和後綴的統稱)指定為序列,以便在一次調用中處理多個詞綴,這一點尚不明確,最後它被從提案中刪除了,等待着其他人再次推動更改。

在 3 月底,Dennis Sweeney 在 python-dev 郵件列表上請求核心開發者支持 PEP 616(“字符串刪除前綴和後綴的方法”)。他指出了自 2019 年 3 月以來關於該話題的 python-ideas 討論。埃里克·史密斯(Eric V. Smith)同意支持該 PEP,這促使 Sweeney 發布並啟動了討論。

在最初版本中,他使用 cutprefix() 和 cutsuffix() 作為要添加給字符串對象的方法名。四種類型的 Python 對象將獲得新的方法:str(Unicode 字符串),byte(二進制序列),bytearray(可變的二進制序列)和 collections.UserString(字符串對象的一種封裝)。

它的寫法如下:

'abcdef'.cutprefix('abc') # 返回'def'
'abcdef'.cutsuffix('ef') # 返回'abcd'

針對命名部分,出現了一大堆的建議。基本上很少有人喜歡“cut”,因此“strip”、“strim”和“remove”被提出來了,並且都獲得了一些支持。

stripprefix() 以及 stripsuffix() 由於 PEP 中指出的一種理由,至少是被部分地反對了;現有的“strip”函數令人困惑,因此應避免重用該名稱。

str.lstrip() 和 str.rstrip() 方法也用於刪除前導字符和尾隨字符,但是它們對於真正在尋找 cutprefix() 功能的程序員來說是一個困惑的來源。

*strip() 在調用時接收一個字符串參數,但會將其視為一組字符,並從字符串開頭或結尾消除:

'abcdef'.lstrip('abc') # 返回“def”,符合預期
'abcbadefed'.lstrip('abc') # 返回'defed',完全不符合預期

最終,removeprefix() 和 removesuffix() 似乎佔據了上風,這正是 Sweeney 最終改成的版本。Guido van Rossum 也支持這些名字。

埃里克·法格倫(Eric Fahlgren)這樣搞笑地總結了命名的爭論:

我認為如果你先寫文檔,則名稱的選擇會更容易些:

cutprefix – 刪除指定的前綴。

trimprefix – 刪除指定的前綴。

stripprefix – 刪除指定的前綴。

removeprefix – 刪除指定的前綴。廢話

Sweeney 更新了 PEP,回應了許多評論,但還增加了提議將字符串元組作為詞綴的功能(可以在 PEP GitHub 倉庫中看到該版本)。

但是史蒂文·達普拉諾(Steven D’Aprano)不確定這樣做是否合理。他指出,唯一接受元組參數的字符串操作是 str.startswith() 和 str.endswith(),而它們不返回字符串(只是一個布爾值)。他懷疑添加這一種接收元組參數卻返回字符串的方法,因為無論選擇何種規則來處理元組,對於某些人來說都是“錯誤的”選擇。

例如:

這裏的困難在於,如果兩個或多個前綴都能匹配,則“剪切這些前綴中的一個”的概念是模稜兩可的。對 startwith 沒有區別:

 "extraordinary".startswith(('ex', 'extra'))

因為是從左到右,從最短到最大,甚至是隨機順序匹配都為True。但是對於 cutprefix,應該刪除哪個前綴?

如他所說,建議的規則是使用從左到右處理元組的第一個匹配字符串,但是有些人可能想要最長的匹配或最後一個匹配;這一切都取決於使用的上下文。他建議在提交添加此類行為之前,要給該功能更多的“浸泡時間”(譯註:即預備時間):“在添加多前綴/後綴的支持之前,我們首先應該對簡單的情況進行一些實際的體驗。”

伊桑·弗曼(Ethan Furman)同意達普拉諾(D’Aprano)的意見。但是維克托·斯汀納(Victor Stinner)強烈贊成元組參數的想法,只不過,他還想知道當傳入的元組有空字符串時,會怎麼處理。根據 PEP 提議,在處理元組時遇到空字符串(實際上可以匹配任何內容)只會返回原始字符串,這會導致令人驚訝的結果:

cutsuffix("Hello World", ("", " World"))    # 返回 "Hello World"
cutsuffix("Hello World", (" World", ""))    # 返回 "Hello"

這個例子不太明顯;詞綴不一定是硬編碼的,因此空字符串可能會溜進意想不到的位置。Stinner 建議如果遇到空字符串,則拋出 ValueError,類似於 str.split()。但是 Sweeney 決定完全刪除元組參數功能,以便“允許對此有更強見解的人在另外的 PEP 中提出並捍衛一系列的語義”。他在 3 月 28 日發布了該 PEP 的最新版本。

4 月 9 日,Sweeney 發起了一個指導委員會 issue,請求對其 PEP 進行評審。4 月 20 日,Stinner 代表委員會接受了該提案。

這是一個很小的更改,但值得花時間確保它具有長期適用的接口(和語義)。我們將在 Python 3.9 中看到 removeprefix() 和removesuffix()。

2、新解析器

並不令人感到驚訝的是,指導委員會已經接受了我們在 4 月中旬介紹過的 CPython 新解析器。PEP 617(“CPython 新的 PEG 解析器”)由 Python 創始人即前仁慈的獨裁者(BDFL) Guido van Rossum 以及 Pablo Galindo Salgado 和 Lysandros Nikolaou 共同提出。

它已經運行良好,並且在現有解析器的速度和內存使用方面提升了 10% 以內的性能。由於解析器是基於解析表達語法(PEG),因此也將簡化語言規範。CPython 現有的 LL(1) 解析器存在諸多缺點和一些 hack,新的解析器將會消除掉。

這一更改為 Python 超越 LL(1) 語法鋪平了道路,儘管現有語言並不完全是 LL(1)。這一更改不會太快,因為計劃是在 Python 3.9 的命令行中提供開關,保持現有解析器可用。

但是 Python 3.10 將刪除現有的解析器,這可能會導致語言變更。如果做了那些更改,那麼,其它的 Python 實現(例如 PyPy 和 MicroPython)就需要切換解析器的 LL(1) 實現,以便跟上語言規範的要求。這可能會使核心開發者暫停進行此類更改。

3、更多內容

我們在三月初查看了 PEP 615(“在標準庫中支持 IANA 時區數據庫”)。它將在標準庫中添加一個zoneinfo 模塊,該模塊將有助於從 IANA 時區數據庫中(也稱為“Olson數據庫”)獲取時區信息,以填充時區對象。在撰寫本文時,它看起來很順利。

在 3 月底,Paul Ganssle 請求就該 PEP 作出決議。他認為在一個有趣的時間範圍內接受它,可能會很有趣:

… 我希望(出於異想天開的原因)在 4 月 5 日(星期日)UTC 時間 02:00-04:00 或 13:00-17:30 之間接受它,因為這些時間代表着地球上某些地方的不明確時間(主要在澳大利亞)。還有另一個時機,那就是在 4 月 19 日星期日 UTC 01:00-03:00 之間,這段時間在西撒哈拉是不明確的。

他意識到這可能難以實現,它當然不是優先考慮的事。指導委員會沒有錯過第二個時間窗太多;Barry Warsaw 於 4 月 20 日宣布接受該 PEP。

Python 現在將具有一種機制來訪問系統的時區數據庫,以創建和處理時區。另外,Python 軟件包索引(PyPI)中有一個 tzdata 模塊,它為缺少 IANA 數據的系統提供這些數據;它將由 Python 核心開發者維護。

PEP 593(“靈活的函數和變量註釋”)添加了一種將上下文特定的(context-specific)元數據與函數和變量關聯的方法。實際上,type hint 註解已擠出了很多年前在 Python 3.0 中實現的 PEP 3107(“函數註釋”)中設想的其它用例。PEP 593 使用註解的(Annotated)類型提示為這些用例創建了一種新的機制。

PEP 585(“標準集合中的類型提示泛型”)提供了另一種清除方法。它將允許刪除在 typing 模塊中維護的一組并行的類型別名,以支持泛型。例如,type.List 類型將不再需要支持諸如“dict[str,list[int]]”之類的註解(例如,一個帶有字符串鍵和整數列表的值的字典)。

字典“加法”的聯合操作也會是 Python 3.9 的一部分。它曾不時引起爭議,但是 2 月中旬,PEP 584(“給字典添加聯合操作符”)被 Van Rossum 推薦採納。指導委員會迅速同意了,該特性於 2 月 24 日合入。

最後一個 PEP 是 PEP 602(“Python 的年度發布周期”)。如提案所書,它將發布節奏從每 18 個月更改為每年一次。但是,開發和發布周期是重疊的,因此整個功能開發需要 12 個月的時間。當第一個 Python 3.9 beta 版本發布時(即現在),Python 3.10 的功能開發就開始了。請繼續關注來年的下一輪 PEP。

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

【其他文章推薦】

※教你寫出一流的銷售文案?

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

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※推薦台中搬家公司優質服務,可到府估價

[原創][開源] SunnyUI.Net 主題

SunnyUI.Net, 基於 C# .Net WinForm 開源控件庫、工具類庫、擴展類庫、多頁面開發框架

  • Blog: https://www.cnblogs.com/yhuse
  • Gitee: https://gitee.com/yhuse/SunnyUI
  • GitHub: https://github.com/yhuse/SunnyUI
  • 幫助文檔目錄: https://www.cnblogs.com/yhuse/p/SunnyUI_Menu.html
  • 歡迎交流,QQ群:  56829229 (SunnyUI技術交流群) 

主題

1、Color 色彩

SunnyUI為了避免視覺傳達差異,使用一套特定的調色板來規定顏色,為你所搭建的產品提供一致的外觀視覺感受。主要顏色參照Element(https://element.eleme.cn/

  • 主色

SunnyUI主要品牌顏色是鮮艷、友好的藍色。

  • 輔助色

除了主色外的場景色,需要在不同的場景中使用(例如紅色表示危險的操作)。

  • 中性色

中性色用於文本、背景和邊框顏色。通過運用不同的中性色,來表現層次結構。

 

2、Rect邊框

我們對邊框進行統一規範,可用於按鈕、卡片、彈窗等組件里。

主要屬性如下:

  • RectColor:邊框顏色
  • RectDisableColor:控件不可用時邊框顏色
  • RectSides:邊框显示方向
  • 無:不显示邊框
  • 全部:显示全部邊框
  • 頂:显示頂部邊框
  • 底:显示底部邊框
  • 左:显示左側邊框
  • 右:显示右側邊框

注:邊框显示和圓角設置相關,如果一側的邊框兩端端點為圓角,則此邊框必定显示。

 

3、Radius圓角

我們提供了以下幾種圓角樣式,以供選擇。默認圓角大小為5px。

主要屬性如下:

Radius:圓角大小

RadiusSides:显示四個角圓角的显示與否

  • 圓角不显示

  • 默認圓角大小為5px

  • 圓角大小與控件高度相等時,显示大圓角

  • 可通過四個角圓角的設置,對控件組合显示

 

4、Font字體

默認字體為:微軟雅黑, 12pt

 

5、Style主題

SunnyUI包含 Element 風格主題 11 個,DotNetBar 主題 3 個,其他主題 2 個,包含主題管理組件 UIStyleManager,可自由切換主題。

  •  UIStyleManager

參考SunnyUI.Demo.exe,將UIStyleManager放置在主窗體上,通過選擇UIStyleManager的屬性Style,或者通過代碼設置統一主題風格。

UIStyleManager.Style = style;

 

  • Style主要屬性如下:

Style:設置主題風格

StyleCustomMode:是否為自定義主題,設置為False時使用UIStyleManager提供的統一主題風格,設置為Ture時可手動調整控件配色,不受UIStyleManager約束。

 

  • UIStyle.Blue

  • UIStyle.Green

  • UIStyle.Orange

  • UIStyle.Red

  • UIStyle.Gray

  • UIStyle.White

  • UIStyle.DarkBlue

  • UIStyle.Black

  • UIStyle.Office2010Blue

  • UIStyle.Office2010Silver

  • UIStyle.Office2010Black

  

原創文章,轉載請保留鏈接 Sunny’s blog

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

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※產品缺大量曝光嗎?你需要的是一流包裝設計!

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

網頁設計最專業,超強功能平台可客製化

最新研究:大氣二氧化碳總量逼近1500萬年來高峰

環境資訊中心綜合外電;姜唯 編譯;林大利 審校

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

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

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

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

※教你寫出一流的銷售文案?

※別再煩惱如何寫文案,掌握八大原則!

工業轉型與綠色振興聲明 就政策、技術、金融三個領域提出建言

文:台大風險政策中心 RSPRC;林怡均翻譯;趙家緯審校

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※推薦評價好的iphone維修中心

網頁設計最專業,超強功能平台可客製化

※別再煩惱如何寫文案,掌握八大原則!

海洋最大謎團——沒人看過鯨鯊生小孩 科學家取得腹部超音波仍無果

環境資訊中心綜合外電;姜唯 編譯;林大利 審校

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨,RWD網頁設計為架站首選

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

※回頭車貨運收費標準

網頁設計最專業,超強功能平台可客製化

※別再煩惱如何寫文案,掌握八大原則!

俄羅斯計畫2032年前清除七艘廢棄核潛艦

摘錄自2020年7月14日自由時報報導

為解決海域核污染問題,俄羅斯正在設計建造能夠打撈沉沒在大海中的核動力潛艦,整個工作預計要進行到2032年。

《Defense World》報導,在第23屆俄羅斯-挪威聯合委員會會議中,改善核能與輻射安全成為主要議題。俄羅斯計畫清除七艘沉沒在北極海域的核潛艇,「K-159」和「K-27」從打撈到拆解預計各自花費四年時間,分別為2025至2028年、2028至2031年,另外5艘則在2029至2032年完成。

報導指出,在1990年代,超過100艘除役的核潛艇被放置在九個不同地點,目前有兩個地點的核潛艇已被清除,自2004年起,放射性廢料減少了一半以上,從1110萬居禮下降至509萬居禮。

能源轉型
國際新聞
俄羅斯
核子潛艦
核污染
核能

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

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

※別再煩惱如何寫文案,掌握八大原則!

網頁設計最專業,超強功能平台可客製化

※回頭車貨運收費標準

邁向碳中合歐盟 擬設統一能源部門

摘錄自2020年7月13日台灣醒報報導

歐洲議會推設立「統一能源部門」,促歐盟各國實現碳中合目標!奧地利的歐洲議員嘉夢日前在一場會議中,提出設立「歐洲統一能源部門」,將協助整合各國現有的能源法規、打造歐盟再生能源中心及促進工業及交通運輸轉型為使用綠色能源,獲得多數議員支持。

歐盟許多成員國包括芬蘭、丹麥已設下2050年以前要實現「碳中合」的目標,即便是將脫歐的英國也曾承諾跟進。根據歐盟調查,為了實現碳中合目標,歐盟整體的用電量將從25%提升到50%,嘉夢說:「實現碳中合,非常需要各國政府機關朝使用綠色能源邁進,因此,我們需要一個部門負責協調整合。」

除了統一各國現有的能源政策及法規外,該部門也將負責打造歐盟再生能源中心、提升各國的太陽能、生物能發電等基礎設施的普及率、研究並部署綠色能源科技,以及協助將乾淨能源的使用範圍擴張到傳統上依賴化石燃料的領域中,例如提倡綠色建築、工業和交通運輸。

能源議題
再生能源
能源轉型
國際新聞
歐盟
碳中和

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

南投搬家公司費用需注意的眉眉角角,別等搬了再說!

※教你寫出一流的銷售文案?

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

疫情害到孤兒象 動保組織難自保

摘錄自2020年7月13日台灣醒報報導

從1977年成立至今的肯亞大象保護組織「雪德瑞克基金會」,因收入短缺,已停止派員保護孤兒象。

根據「世界自然基金會」2019年的報告指出,非洲在地的動保組織重要性極高,他們預估,如果放任盜獵行為或讓大象繼續闖入人類地盤與人發生衝突,以這樣的速率發展,非洲大象將滅在2040年完全滅絕。

據《獨立報》報導,無獨有偶,泰國觀光景點的大象也面臨生死存亡的處境。儘管近幾年來泰國一再有虐待大象的事情發生,也被抨擊利用大象賺錢不人道,但據當地業者表示,現在讓動物們吃飽已成為當務之急。每天餵食一頭大象的成本可高達40美元,是泰國人每日基本薪資的3倍以上,大象聯盟協會主席舂布拉干表示,除非政府伸出援手,否則這些大象將被迫重回街頭,或進行非法砍伐。

物種保育
生物多樣性
土地利用
國際新聞
非洲
泰國
武漢肺炎
動物與大環境變遷
大象
大象盜獵
動物保護組織
貧窮

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※回頭車貨運收費標準

重學 Java 設計模式:實戰裝飾器模式(SSO單點登錄功能擴展,增加攔截用戶訪問方法範圍場景)

作者:小傅哥
博客:https://bugstack.cn

沉澱、分享、成長,讓自己和他人都能有所收穫!

一、前言

對於代碼你有編程感覺嗎

很多人寫代碼往往是沒有編程感覺的,也就是除了可以把功能按照固定的流程編寫出流水式的代碼外,很難去思考整套功能服務的擴展性和可維護性。尤其是在一些較大型的功能搭建上,比較缺失一些駕馭能力,從而導致最終的代碼相對來說不能做到盡善盡美。

江洋大盜與江洋大偷

兩個本想描述一樣的意思的詞,只因一字只差就讓人覺得一個是好牛,一個好搞笑。往往我們去開發編程寫代碼時也經常將一些不恰當的用法用於業務需求實現中,當卻不能意識到。一方面是由於編碼不多缺少較大型項目的實踐,另一方面是不思進取的總在以完成需求為目標缺少精益求精的工匠精神。

書從來不是看的而是用的

在這個學習資料幾乎爆炸的時代,甚至你可以輕易就獲取幾個T的視頻,小手輕輕一點就收藏一堆文章,但卻很少去看。學習的過程從不只是簡單的看一遍就可以,對於一些實操性的技術書籍,如果真的希望學習到知識,那麼一定是把這本書用起來而絕對不是看起來。

二、開發環境

  1. JDK 1.8
  2. Idea + Maven
  3. 涉及工程三個,可以通過關注公眾號bugstack蟲洞棧,回復源碼下載獲取(打開獲取的鏈接,找到序號18)
工程 描述
itstack-demo-design-9-00 場景模擬工程;模擬單點登錄類
itstack-demo-design-9-01 使用一坨代碼實現業務需求
itstack-demo-design-9-02 通過設計模式優化改造代碼,產生對比性從而學習

三、裝飾器模式介紹

初看上圖感覺裝飾器模式有點像俄羅斯套娃、某眾汽車,而裝飾器的核心就是再不改原有類的基礎上給類新增功能。不改變原有類,可能有的小夥伴會想到繼承、AOP切面,當然這些方式都可以實現,但是使用裝飾器模式會是另外一種思路更為靈活,可以避免繼承導致的子類過多,也可以避免AOP帶來的複雜性。

你熟悉的場景很多用到裝飾器模式

new BufferedReader(new FileReader(""));,這段代碼你是否熟悉,相信學習java開發到字節流、字符流、文件流的內容時都見到了這樣的代碼,一層嵌套一層,一層嵌套一層,字節流轉字符流等等,而這樣方式的使用就是裝飾器模式的一種體現。

四、案例場景模擬

在本案例中我們模擬一個單點登錄功能擴充的場景

一般在業務開發的初期,往往內部的ERP使用只需要判斷賬戶驗證即可,驗證通過後即可訪問ERP的所有資源。但隨着業務的不斷髮展,團隊里開始出現專門的運營人員、營銷人員、數據人員,每個人員對於ERP的使用需求不同,有些需要創建活動,有些只是查看數據。同時為了保證數據的安全性,不會讓每個用戶都有最高的權限。

那麼以往使用的SSO是一個組件化通用的服務,不能在裏面添加需要的用戶訪問驗證功能。這個時候我們就可以使用裝飾器模式,擴充原有的單點登錄服務。但同時也保證原有功能不受破壞,可以繼續使用。

1. 場景模擬工程

itstack-demo-design-9-00
└── src
    └── main
        └── java
            └── org.itstack.demo.design
                ├── HandlerInterceptor.java
                └── SsoInterceptor.java
  • 這裏模擬的是spring中的類:HandlerInterceptor,實現起接口功能SsoInterceptor模擬的單點登錄攔截服務。
  • 為了避免引入太多spring的內容影響對設計模式的閱讀,這裏使用了同名的類和方法,盡可能減少外部的依賴。

2. 場景簡述

2.1 模擬Spring的HandlerInterceptor

public interface HandlerInterceptor {

    boolean preHandle(String request, String response, Object handler);

}
  • 實際的單點登錄開發會基於;org.springframework.web.servlet.HandlerInterceptor 實現。

2.2 模擬單點登錄功能

public class SsoInterceptor implements HandlerInterceptor{

    public boolean preHandle(String request, String response, Object handler) {
        // 模擬獲取cookie
        String ticket = request.substring(1, 8);
        // 模擬校驗
        return ticket.equals("success");
    }

}
  • 這裏的模擬實現非常簡單隻是截取字符串,實際使用需要從HttpServletRequest request對象中獲取cookie信息,解析ticket值做校驗。
  • 在返回的裏面也非常簡單,只要獲取到了success就認為是允許登錄。

五、用一坨坨代碼實現

此場景大多數實現的方式都會採用繼承類

繼承類的實現方式也是一個比較通用的方式,通過繼承后重寫方法,併發將自己的邏輯覆蓋進去。如果是一些簡單的場景且不需要不斷維護和擴展的,此類實現並不會有什麼,也不會導致子類過多。

1. 工程結構

itstack-demo-design-9-01
└── src
    └── main
        └── java
            └── org.itstack.demo.design
                └── LoginSsoDecorator.java
  • 以上工程結構非常簡單,只是通過 LoginSsoDecorator 繼承 SsoInterceptor,重寫方法功能。

2. 代碼實現

public class LoginSsoDecorator extends SsoInterceptor {

    private static Map<String, String> authMap = new ConcurrentHashMap<String, String>();

    static {
        authMap.put("huahua", "queryUserInfo");
        authMap.put("doudou", "queryUserInfo");
    }

    @Override
    public boolean preHandle(String request, String response, Object handler) {
        // 模擬獲取cookie
        String ticket = request.substring(1, 8);
        // 模擬校驗
        boolean success = ticket.equals("success");

        if (!success) return false;

        String userId = request.substring(9);
        String method = authMap.get(userId);

        // 模擬方法校驗
        return "queryUserInfo".equals(method);
    }

}
  • 以上這部分通過繼承重寫方法,將個人可訪問哪些方法的功能添加到方法中。
  • 以上看着代碼還算比較清晰,但如果是比較複雜的業務流程代碼,就會很混亂。

3. 測試驗證

3.1 編寫測試類

@Test
public void test_LoginSsoDecorator() {
    LoginSsoDecorator ssoDecorator = new LoginSsoDecorator();
    String request = "1successhuahua";
    boolean success = ssoDecorator.preHandle(request, "ewcdqwt40liuiu", "t");
    System.out.println("登錄校驗:" + request + (success ? " 放行" : " 攔截"));
}
  • 這裏模擬的相當於登錄過程中的校驗操作,判斷用戶是否可登錄以及是否可訪問方法。

3.2 測試結果

登錄校驗:1successhuahua 攔截

Process finished with exit code 0
  • 從測試結果來看滿足我們的預期,已經做了攔截。如果你在學習的過程中,可以嘗試模擬單點登錄並繼承擴展功能。

六、裝飾器模式重構代碼

接下來使用裝飾器模式來進行代碼優化,也算是一次很小的重構。

裝飾器主要解決的是直接繼承下因功能的不斷橫向擴展導致子類膨脹的問題,而是用裝飾器模式后就會比直接繼承顯得更加靈活同時這樣也就不再需要考慮子類的維護。

在裝飾器模式中有四個比較重要點抽象出來的點;

  1. 抽象構件角色(Component) – 定義抽象接口
  2. 具體構件角色(ConcreteComponent) – 實現抽象接口,可以是一組
  3. 裝飾角色(Decorator) – 定義抽象類並繼承接口中的方法,保證一致性
  4. 具體裝飾角色(ConcreteDecorator) – 擴展裝飾具體的實現邏輯

通過以上這四項來實現裝飾器模式,主要核心內容會體現在抽象類的定義和實現上。

1. 工程結構

itstack-demo-design-9-02
└── src
    └── main
        └── java
            └── org.itstack.demo.design
                ├── LoginSsoDecorator.java
                └── SsoDecorator.java

裝飾器模式模型結構

  • 以上是一個裝飾器實現的類圖結構,重點的類是SsoDecorator,這個類是一個抽象類主要完成了對接口HandlerInterceptor繼承。
  • 當裝飾角色繼承接口後會提供構造函數,入參就是繼承的接口實現類即可,這樣就可以很方便的擴展出不同功能組件。

2. 代碼實現

2.1 抽象類裝飾角色

public abstract class SsoDecorator implements HandlerInterceptor {

    private HandlerInterceptor handlerInterceptor;

    private SsoDecorator(){}

    public SsoDecorator(HandlerInterceptor handlerInterceptor) {
        this.handlerInterceptor = handlerInterceptor;
    }

    public boolean preHandle(String request, String response, Object handler) {
        return handlerInterceptor.preHandle(request, response, handler);
    }

}
  • 在裝飾類中有兩個重點的地方是;1)繼承了處理接口、2)提供了構造函數、3)覆蓋了方法preHandle
  • 以上三個點是裝飾器模式的核心處理部分,這樣可以踢掉對子類繼承的方式實現邏輯功能擴展。

2.2 裝飾角色邏輯實現

public class LoginSsoDecorator extends SsoDecorator {

    private Logger logger = LoggerFactory.getLogger(LoginSsoDecorator.class);

    private static Map<String, String> authMap = new ConcurrentHashMap<String, String>();

    static {
        authMap.put("huahua", "queryUserInfo");
        authMap.put("doudou", "queryUserInfo");
    }

    public LoginSsoDecorator(HandlerInterceptor handlerInterceptor) {
        super(handlerInterceptor);
    }

    @Override
    public boolean preHandle(String request, String response, Object handler) {
        boolean success = super.preHandle(request, response, handler);
        if (!success) return false;
        String userId = request.substring(8);
        String method = authMap.get(userId);
        logger.info("模擬單點登錄方法訪問攔截校驗:{} {}", userId, method);
        // 模擬方法校驗
        return "queryUserInfo".equals(method);
    }
}
  • 在具體的裝飾類實現中,繼承了裝飾類SsoDecorator,那麼現在就可以擴展方法;preHandle
  • preHandle的實現中可以看到,這裏只關心擴展部分的功能,同時不會影響原有類的核心服務,也不會因為使用繼承方式而導致的多餘子類,增加了整體的靈活性。

3. 測試驗證

3.1 編寫測試類

@Test
public void test_LoginSsoDecorator() {
    LoginSsoDecorator ssoDecorator = new LoginSsoDecorator(new SsoInterceptor());
    String request = "1successhuahua";
    boolean success = ssoDecorator.preHandle(request, "ewcdqwt40liuiu", "t");
    System.out.println("登錄校驗:" + request + (success ? " 放行" : " 攔截"));
}
  • 這裏測試了對裝飾器模式的使用,通過透傳原有單點登錄類new SsoInterceptor(),傳遞給裝飾器,讓裝飾器可以執行擴充的功能。
  • 同時對於傳遞者和裝飾器都可以是多組的,在一些實際的業務開發中,往往也是由於太多類型的子類實現而導致不易於維護,從而使用裝飾器模式替代。

3.2 測試結果

23:50:50.796 [main] INFO  o.i.demo.design.LoginSsoDecorator - 模擬單點登錄方法訪問攔截校驗:huahua queryUserInfo
登錄校驗:1successhuahua 放行

Process finished with exit code 0
  • 結果符合預期,擴展了對方法攔截的校驗性。
  • 如果你在學習的過程中有用到過單點登陸,那麼可以適當在裏面進行擴展裝飾器模式進行學習使用。
  • 另外,還有一種場景也可以使用裝飾器。例如;你之前使用某個實現某個接口接收單個消息,但由於外部的升級變為發送list集合消息,但你又不希望所有的代碼類都去修改這部分邏輯。那麼可以使用裝飾器模式進行適配list集合,給使用者依然是for循環后的單個消息。

七、總結

  • 使用裝飾器模式滿足單一職責原則,你可以在自己的裝飾類中完成功能邏輯的擴展,而不影響主類,同時可以按需在運行時添加和刪除這部分邏輯。另外裝飾器模式與繼承父類重寫方法,在某些時候需要按需選擇,並不一定某一個就是最好。
  • 裝飾器實現的重點是對抽象類繼承接口方式的使用,同時設定被繼承的接口可以通過構造函數傳遞其實現類,由此增加擴展性並重寫方法里可以實現此部分父類實現的功能。
  • 就像夏天熱你穿短褲,冬天冷你穿棉褲,雨天挨澆你穿雨衣一樣,你的根本本身沒有被改變,而你的需求卻被不同的裝飾而實現。生活中往往比比皆是設計,當你可以融合這部分活靈活現的例子到代碼實現中,往往會創造出更加優雅的實現方式。

八、推薦閱讀

  • 1. 重學 Java 設計模式:實戰工廠方法模式(多種類型商品發獎場景)
  • 2. 重學 Java 設計模式:實戰抽象工廠模式(替換Redis雙集群升級場景)
  • 3. 重學 Java 設計模式:實戰建造者模式(裝修物料組合套餐選配場景)
  • 4. 重學 Java 設計模式:實戰原型模式(多套試每人題目和答案亂序場景)
  • 5. 重學 Java 設計模式:實戰橋接模式(多支付渠道「微信、支付寶」與多支付模式「刷臉、指紋」場景)
  • 6. 重學 Java 設計模式:實戰組合模式(營銷差異化人群發券,決策樹引擎搭建場景)

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

【其他文章推薦】

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

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

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

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※回頭車貨運收費標準