你不用懷疑,這是真的。筆者在2008年所寫的這本書,現在全部全文開放免費下載,而且沒有時限。
[ASP.NET][碎碎念] ASP.NET 問題解決實戰 全書開放電子檔 - 以及台灣技術書市的警訊
- 162944
- 0
- ASP.NET - Web Forms and Core Development
- 2021-11-04
你不用懷疑,這是真的。筆者在2008年所寫的這本書,現在全部全文開放免費下載,而且沒有時限。
這一份是我幫駐點的公司所設計的一份程式碼與資料結構的命名與設計規範,應觀眾要求,先把一些駐點公司的資料清除以後貼上來,不定時更新,如果對這個有特別想法的也可以提出來,可以隨時更新這個規範的內容。
網路上有些文章會教學員在安裝完 SQL Server 後,一併打開 TCP Port 1433,但若主機有對 Internet,且系統和 SQL Server 同一台,這反而是個很危險的行為。
最近看了一些文章,發現有些人對這三個模式似乎仍有些誤解,之前曾經有寫過一篇這樣的文章,這回就再深入一點討論它們的差別吧。
隨著 DDD 的崛起,愈來愈多人開始討論所謂的貧血模型 (Anemic Domain Model),然後就開始有人指責這樣的設計怎樣怎樣 (像是物件導向沒學好之類的),但是既然是一個流行已久的設計方式,事出必有因,先理解它是怎麼出現的再來評論或批判或許會比一股腦批判要好的多。
之前其實就有想寫這一篇,但是因為很忙而擱著,今天看到了某些網路文章,才讓我起意把這篇補起來。早期我寫了一系列關於架構師先決條件的文章 "邁向架構師的暖身運動",簡單說明了怎麼由架構的角度去思考系統設計的方略,今天就用這篇文章將它做個總結吧 (謎之音:其實是你自己懶吧)。
SQL 的 ORDER BY 會執行資料的重新排序,然後輸出給上層查詢或輸出給用戶端,開發實務上 ORDER BY 的情況非常常見,就跟呼吸一樣自然,但是 ORDER BY 對一個設計不良的資料庫可以說是一個大災難,因為它排序的對象是結果集,若結果集愈大,ORDER BY 會拖慢效能,但適當的設計可以減少 ORDER BY 對效能的損耗。
在資料庫設計上,PK (主鍵) 一直都是設計的重點之一,但主鍵使用的資料型態有可能直接或間接影響到資料庫的存取效能,然而技術是會演進的,30年前可能不行的作法在30年後的今天是否仍然不適用? 似乎有待商榷。
Delegate 和 Lambda 的概念在 2008 年就出來了,Delegate 更是最早最早 (.NET 1.0) 時就已經有的概念,隨著技術的演進,Lambda 讓 Delegate 變得更好使用也更容易發揮,但似乎有些人不這麼認為,所以我還是再講一些吧。
開放原始碼 (Open Source) 早已成為推進資訊科技進步的主要動力來源,且也是出自許多在世界各個角落高手為持續帶動資訊科技進步的貢獻,然而有些時候在取用或在使用這些開源專案的成果時,會不會有可能不小心誤觸了某些陷阱? 這或許是所有軟體開發者都要關注的點。
因為相依注入 (Dependency Injection) 的日漸盛行,使得相依反轉原則 (Dependency Inversion Principle, DIP) 這個詞被愈用愈多,它的說明是 "將原本相依於低階實作的相依性,轉換為相依至高階抽象",不過這個高階和低階的意義是什麼? 我想要再多闡述一下。
C# 的 var 是極度的好物,它可以幫你解決長名稱或容易弄錯的型別的自動轉換,但如果用 var 只是拿來規避重構所產生的物件設計問題,那其實只是鴕鳥心態而已。
在標題上連續寫三次,實在是因為太多人把雜湊當加密看待,不只是錯得離譜,還有可能會害到客戶。
在四人幫 (GoF) 的設計模式 (Design Patterns) 一書中,最容易被用到的模式,非策略模式 (Strategy Pattern) 莫屬了,不過也就是因為它太容易被用到,它也是很容易被誤會的一種設計模式,特別是和多型 (Polymorphism) 的混淆。
因為最近分層架構的流行 (拜三隻豬之賜?),愈來愈多人談論起 Repository 的設計,也開始有人認為 Repository 無用,說實在的,Repository 有用於否,存乎一心,當你認為它有用時,隨手寫了它也不會覺得奇怪,但如果一開始就認為它是多餘的,就算人家給你程式產生器,你還是會認為它是多餘的。
昨天有個自稱 ASP.NET Web Form 界最強的大作者,寫了一篇文章,裡面說使用 Windows 驗證連線資料庫是最不建議的作法,但這只是凸顯該大作者一點都不懂資訊安全的其中一個點而己,殊不知他認為的最不建議的作法,卻是 Microsoft 官方最建議的作法。
最近 Cloud Computing 的幾個指標性的供應商,包含 Microsoft, Amazon, Google 等,都相繼提出了邊界運算 (又稱邊際運算) 的概念,其實說穿了,只是分久必合,合久必分的循環而己。
Azure Function 真的太好用了,以往 Web Job 能做的事都可以交給它來做,包含日常的維護,本文的重新啟動 Azure Web App 就是個例子。
在資料表結構 (table schema) 中,每個欄位除了基本的欄位名稱、型態、大小等資料外,有一個有趣的欄位很特別,就是是否允許 NULL,NULL 這個東西對程式設計師來說是又愛又恨,有時會被它搞得嫑嫑的,但是它有時卻又是一個有必要的存在。
昨天在 "C# 7 不能編譯?" 一文的最後,我有提到不是一定要 Visual Studio 2017 才能使用 C# 7,只要 Microsoft.Net.Compilers 可以運作 (.NET 4.5.1 以上),就能使用 C# 7 快樂的寫程式,有朋友回應說 Visual Studio 2015 上使用 C# 7 ,Microsoft.Net.Compilers 已經升級到 2.0,但卻無法編譯... (這個問題要解決有個但書)
Azure 在以前服務管理模式 (Service Management Mode) 下最大的問題之一就是無法快速佈建大量的虛擬機器,這個問題雖然在管理機制升級到資源管理模式 (Resource Management Mode) 後似乎有改善的狀況,但在 ARM 初期,只是改變了 VM 各資源的組成方式,沒有真正解決快速部署的問題,這個問題一直到 Azure 發表了虛擬機器擴展集 (VMSS) 後才真的得到解決,不過網路上用的幾乎都是使用 Resource Template 的作法,這篇文章要教授如何使用 Azure PowerShell 來做到這件事,而且還是用自訂的作業系統映像,而不是平台本身的。
C# 7 隨著 Visual Studio 2017 出爐後,相信大家一定是躍躍欲試,好好的利用 C# 7 各式的語法糖 (誤) 來簡化寫碼的工作,但是如果你是由 Visual Studio 2015 升上來的 C# 專案,可能會遇到無法使用 C# 7 語法的問題,其實解決方案很簡單的...
Visual Studio 2017 將於 3/8 零時 (台灣時間) 正式發表,在發表的前數個小時,MSDN 訂閱者下載區已經有 Visual Studio 2017 的安裝程式放上去了,不過並沒有發布 ISO 檔案,Visual Studio Community 2017 也是,因此特別說明如何建立一份可離線安裝 (Offline Installation) 的媒體,以利在沒有網路時進行安裝。
今年是 Visual Studio 的二十歲生日,要說資深的 Visual Studio 愛用者,我應該也可以算一個吧,在我最早開始學習程式開發時,Visual Studio 都還沒出來喔。既然 VS 20 歲了,那我也稍微的寫點文字來慶祝一下 VS 20 週年吧。不過因為我比較擅長實事描寫,要看逢迎拍馬內容的就甭進來了。
相信之前已經有很多朋友看過我在 2009 年寫的拙作,但時空交替與變化,為求用字精準,故重寫本篇文章,重新且精確的闡述 MVP 的意義。
晚期繫結是一種程式語言與作業系統的手法,用意在於避免因為編譯時期的型別檢查機制,導致程式員在編寫程式時,需要處理過多的型別資訊 (Type Information),晚期繫結可以有效的處理在平台之間型別資訊的隔離,讓編譯出來的程式可以在特定的平台之間執行,而不需要被型別資訊綁住,不過也不能過度濫用,除非原生平台就是要用晚期繫結 (例如 JavaScript)。
這是一個很有趣的問題,當初我在編寫 ASP.NET MVC 5 網站開發美學 CH4 (4.6.5) 的實作繼承時,使用的是已有 Database 和 Table Schema 的狀況,沒有注意到 Database Creation 時的狀況,這個問題是由讀者反應,我做了個實驗才發現這個問題,但解決方法也很簡單,在此留下記錄以供其他讀者查閱。
現在網路和分享這麼發達,你可以很容易的搜尋到很多公司或人分享出來的系統架構,舉凡 Stackoverflow、淘寶、百度或是其他公司實作一個解決方案的整體架構,用來當參考架構 (Referential Architecture) 是很棒的藍圖,不過它就只是個 "藍圖",你所不知道的是他們花了多少錢去做,或許一個人用雲端也可以做到,但是並沒有減少它應有的成本,就像你不可能妄想用一台 VM (裡面即使跑得動十萬台 Docker Container) 來服務一億個使用者一樣。
Azure Function 是微軟在 Build 2016 時宣佈的新服務,它和之前 Amazon 的 AWS Lambda 以及 Google 的 Cloud Function 一樣,都是 Serverless 型的運算應用,適合作為以事件驅動方式觸發的小程式,而且開發人員不需要在乎它被執行的環境的細節,只需要寫好程式丟上去就行了。