[研究]ASP.NET Core 2 關於 DI 使用的變數為什麼是唯讀屬性

-

ASP.NET Core 每次在使用 DI 時，通常都會在 接收 DI 服務的變數宣告上使用了 readonly 的形式？

雖然不使用 readonly 也是可以使用，但是這樣做的主要目的是當 DI 服務備要求導入此變數時，可以確保此變數指向的物件(服務)，不會被其它程式碼變更。以免發生 exception。

那麼，很奇怪的是，既然是宣告為 readonly ，為什麼又可以被指定內容(如上圖)，很明確的原因有2個：

1、readonly 屬性是在建構(Construction)後才生效，所以在 Constructor 時，是可以指定內容的。
2、readonly 屬性是給編譯器進行檢查用，以確保範圍內(Scope)的程式碼不會對此變數進行內容指派的動作，建構函數執行期除外。


參考：Why is this field declared as private and also readonly?









留言

張貼留言

這個網誌中的熱門文章

【研究】列印的條碼為什麼很難刷(掃描)

-
圖片
條碼在我們的世界無處不在，小至發票，大至大型裝置設備都會有它的身影。 每一家有制度化的公司，多少都會需要用到條碼來進行管理，身為開發人員，就很難不會碰到它。 但是我們常常因為不熟悉條碼的規則，而導致作出來的條碼沒辦法被讀取(掃描)，也常遇到A設備可以讀取，B設備就無法讀取的奇怪現象，當然讀取設備本身的讀取元件也是有功力上的差別，有些廠商有能力可以調教讀寫元件的設定。 接下來，我就做點實驗給大家知道這個條碼的問題出在哪裡，以便在往後使用條碼時可以更注意到發生的原因。 在這裡我不再重述條碼的來由，這次的比較是使用大家常用的Code39(又稱39碼)來比較。 使用39碼得主要是因為他有字型檔可以使用，可以拿來做比較。 條碼的列印方式分類與優缺： 一、由條碼機(又稱標籤機)內建指令列印 優點：線條清晰，掃描讀取容易、速度快。             列印特殊紙張(背膠式、連續型.....) 缺點：特殊的指令語言(每一個廠牌都不太一樣)，等於換機器就要改寫程式碼。             有一些貼心的廠商(精聯)會提供比較簡單的統一語言列印工具，減少開發者困擾。             版面變化較少，沒有視覺化編輯。 二、由Windows Driver列印，或稱普通列印 優點：只要有驅動程式就可以列印，不需要改寫程式(或改寫幅度小)。            版面彈性比較自由。由於只要有驅動就可以列印，            所以比較不限定紙張種類，或印表機種類。 缺點：列印線條有很多模糊地帶，沒控制好就會導致無法讀取。            受到列印裝置解析度限制，匹配沒做好就會失敗。 底下先做出三種情境比較： 雷射印表機：600DPI 條碼印表機(標籤機)：203DPI 這裡，我們先 比較印表機解析度的列印差異 ，請忽略機器種類。
裡面更多內容 》》》

統一發票列印小程式

-
圖片
1、請注意本版留言過多， 您的留言可能不在這一頁，請到以下留言樓層看看再回應喔～  2、如果您有填寫表單，卻沒有收到我的郵件，有可能您填寫的電子郵件有錯誤，麻煩您查看一下留言是否有我給您的信息喔。因為我沒辦法直接連繫到您。 1 ~200 則，請按這裡   200+ 以上請按這裡 因為公司會在一堆系統上都有可能要印發票(真不懂要怎麼搞?) 希望可以有個小工具可以列印電子發票， 原本發票列印程式要使用條碼機專用語言(ZPL、EPL)，但容易被某種機型綁定。 當然可以考慮使用ESC/POS指令的方式，但也是要印表機支援這種指令列印模式(當然多數表機都有支援)，不過要列印QR碼，就有點不是那麼容易了，除了要自己編碼外還要注意中文問題。 後來我想改用Windows Printer Driver來列印，雖然不如指令式快速，但可以方便各類型程式應用，因此考慮了以下的條件： 使用C#開發、.Net 2.0平台、Console呼叫 本來想用RDLC來做，但是很不幸的，失敗了，原因就在於條碼， 國稅局訂定的Code39條碼內要放入21個字元(19+2)長度， 如果使用RDLC的話，解析度只有100DPI，密度不夠，條碼線條沾黏嚴重。 一般的條碼機至少都有200DPI得等級，這RDLC也太彆腳了吧， 網路上找盡RDLC條整解析度的方式都沒有比較好的效果。 因此，改用直接C#繪製的方式來做， 當然中間為了條碼圖像清晰度的問題花了不少心力解決。 下載點： PrintInvoice
裡面更多內容 》》》

C# 使用 Process.Start 執行外部程式

-
圖片
C# 執行外部程式的方式並不難，也很簡單，首先引入 using System.Diagnostics; 然後使用 Process.Start( "OtherProgram.exe" ) 方式就可以呼叫並執行。 但是，某些情況下會導致程式無法被執行(或是無法正常執行)， 很多原因在於『執行程式的起始位置』，由於被呼叫的程式執行時， 它所啟動的路徑其實是在呼叫程式的路徑下， 如果被呼叫程式需要讀取與程式相同路徑下的文件檔案(或是INI)，可能會導致找不到的問題。 為了測試這樣的現象，我準備了2支程式， 一支是被呼叫端的程式 HelloConsole.exe 另外一支就是呼叫端程式 CallOtherProgram.exe HelloConsole.exe 這支程式 在啟動時會讀取相同路徑下的 Doc.txt 並將內容顯示出來，如果有參數也會把參數列出來。而這支程式我固定放在 D:\TEST\ 下，以方便測試，如果不是在這路徑下，那呼叫端的程式碼裡面的路徑也要變更。 HelloConsole.exe using System; using System.IO; namespace HelloConsole {     class Program     {         static void Main(string[] args)         {             Console.WriteLine("This is HelloConsole.exe");             Console.WriteLine(" ");             Console.WriteLine("Environment.CurrentDirectory is ");             Console.WriteLine(Environment.CurrentDirectory);             Console.WriteLine(" ");             Console.WriteLine("AppDomain.CurrentDomain.BaseDire
裡面更多內容 》》》