Mr.Wei 的程式筆記

2014年7月31日星期四

你所不知道的 JS

開發時期：

撰寫 Javascrip 的時候
無法宣告型別

執行時期：

Javascrip 在瀏覽器上運行的時候
會檢查型別

廣義物件：

所有東西都是物件(廣義)
物件是存放在記憶體中的資料
存在於執行時期

狹義物件：

JavaScript 是由 Object 所組成。Array 是物件、Function 是物件、Objects 是物件。
在 JavaScript 的原生資料型態 (Primitive Data Type) 中，只有下列五種類型的「值」(value) 不被視為物件：

Numbers 數值
Strings 字串值
Booleans 布林值
null 空值
undefined 未定義值

其它的所有東西，都算是物件的一種

物件：

物件只能靠變數或屬性取用
物件是個容器，海納百川有容乃大
物件是個雜湊陣列(HashMap)
物件只包含屬性 (Property) 跟方法 (Method or Function)
可以直接取得值的稱作屬性，可以執行的稱作方法

var name = obj.name;
obj.laughOutLoud();

型別：

分為原始型別跟物件型別
原始型別 number string boolean 有其對應的 原始型別包裹 Number String Boolean
不建議直接使用原始型別包裹

變數：

Javascrip 是動態語言 不需編譯就能執行
宣告變數用 var
有全域變數跟區域變數兩種
除非有其非常必要性，否則盡量避免使用全域變數，避免互相影響跟衝突
建立變數的時候會同時建立屬性及變數

在全域的時候會在根物件建立屬性，這會使得任何地方都能夠過跟物件的該屬性作存取
在區域的時候會在內部物件建立屬性，內部物件是個隱形人，你看不到也摸不到他，但是他確實存在

區域變數的作用域只以 function 區隔與一般 if for while 大括號範圍無關，故一個 function 內的所有變數都可能會互相影響跟衝突
要避免一個 function 內的變數互相影響跟衝突，除了注意命名之外，拆解成數個 function 會是較佳的做法
開發時期可以在任何位置使用 var 宣告變數，但是這些變數會在執行時期自動宣告在 function 內的頂端，他只會將變數名稱的宣告置頂(其值為 undefined)，賦值的位置仍不變，這種特性稱為 Hoisting，這也是為何 function 內的變數不受大括號範圍影響的原因
小道消息指出，大多數人甚至開發 Javascrip 數十年的開發人員，都鮮少有人知道 Hoisting

2014年6月27日星期五

LINQ 動態查詢 LINQKit PredicateBuilder + Glimpse 效能監測

早在 2013 LINQ 動態查詢就困擾著我

http://weisnote.blogspot.tw/2013/03/dynamic-linq.html

當時找到 Dynamic LINQ

但是組字串並不是個好法子

(要組字串的話我何不直接用 Pure T-SQL)

曾經與 LINQ 纏鬥過的朋友都知道動態查詢很難搞

尤其是 Or

並沒有什麼內建的法子可以讓你動態來 Or Or Or

要不就寫死 .Where(x => x.Foo == 'Foo' || x.Bar == 'Bar || x.Goo == 'Goo' || x.Nar == 'Nar'')

要不就 Expression Trees 硬幹像這樣

靠自己好自在...才怪

賣鬧啊 Expression Trees 學習曲線可沒比 Regular Expression 低 (雖然小弟兩樣都沒學好)

如今 2014 了技術是會進步的!!

(其實應該出來滿久的只是我沒去玩他)

拜讀於此:

援助教技--IT點滴日誌:http://neo-tech-tw.blogspot.tw/2013/08/linq-predicatebuilder.html

繼續沉睡5000年:http://leaflet-t-h.blogspot.tw/2011/11/linq-predicatebuilder.html

Kelp Code:http://kelp.phate.org/2011/12/linq-to-object-linqkitpredicatebuilder.html

鄭重歡迎 ~ LINQKit http://www.albahari.com/nutshell/linqkit.aspx

LINQKit 裡面應該是有不少妖魔鬼怪的但是今天只來玩 PredicateBuilder 來搞定 Or Or Or

照官網範例很簡單就完成了

靠大神好爽...正解

其中比較讓人困惑的可能就是這句

var predicate = PredicateBuilder.False<Products>();

它的完整型別長這樣

Expression<Func<Products, bool>> predicate = PredicateBuilder.False<Products>();

更不懂了?? 其實他就下面這東東

Expression<Func<Products, bool>> predicate = x => false;

至於什麼時候用 PredicateBuilder.True<T> 什麼時候用 PredicateBuilder.False<T> 則是看接起來是什麼結果

簡單來說如果都是 Or 用 PredicateBuilder.False<T> 如果都是 And 用 PredicateBuilder.True<T>

眼尖的考究帝一定有發現瀏覽器下面有一條鬼東西

那是最近神人傳授的好物 Glimpse

不僅美觀功能更甚 MiniProfiler

Glimpse 官網http://getglimpse.com/Docs/

怎麼裝就不用講了 Nuget~催落去

真要說有什麼缺點的話大概就是螢幕太小很麻煩因為他內容很多非常寬 : P

2014年6月22日星期日

一秒看破樞紐查詢 SQL PIVOT UNPIVOT LINQ

什麼是樞紐?

......

弄點假資料(手 KEY 就太傻太天真)

查出來這樣

但是 User 要這樣

硬幹吧男孩 For~For~For~

多想兩分鐘，你可以不必自殺

官方有解 MS SQL 2005 + 都能玩

http://technet.microsoft.com/zh-tw/library/ms177410(v=sql.105).aspx

SELECT <非樞紐資料行>,

[第一個樞紐資料行] AS <資料行名稱>,

[第二個樞紐資料行] AS <資料行名稱>,

...

[最後一個樞紐資料行] AS <資料行名稱>

FROM

(<產生資料的 SELECT 查詢>)

AS <來源查詢的別名>

PIVOT

(

<彙總函式>(<要彙總的資料行>)

FOR

[<包含將變成資料行標頭之值的資料行>]

IN ( [第一個樞紐資料行], [第二個樞紐資料行],

... [最後一個樞紐資料行])

) AS <樞紐分析表的別名>

<選擇性的 ORDER BY 子句>;

WTF...

看圖 (那堆欄位沒法直接用 SQL 搞死心吧只能靠 C# 組字串)

用 WITH 能略顯風騷???

沒了

等等...UNPIVOT 勒?

官網說就是把 PIVOT 反過來

WTF...

有張反正規化的表

翻滾吧 Table

沒了

等等...LINQ 勒?

: P

http://abundantcode.com/how-to-create-pivot-data-using-linq-in-c/

http://linqlib.codeplex.com/wikipage?title=Pivot

逃

2014年5月20日星期二

ASP.NET Web Form 對應優先設計 (Mapping-First Design) 第三彈 - 被遺忘者

PM 常說先求有再求好

PG 就說 no problem!

於是三兩下搞定了 CRUD 交給 USER

然後立馬被玩壞

因為 USER 總是能夠超越極限在 TextBox 裡面塞入無限的可能性

顯而易見我們需要類似這種東東防止 USER 的無限加速器全開

或許反射性的就想到工具箱裡面的好碰友...

but that was out of fashion

既然前面兩彈大費周章的弄了一個 values mapping system

又在每彈結尾留可有可無的伏筆

自然就是要在上面搞些花招

已達更加無腦的境界

首先從 Map 發想

我希望這樣子來使用欄位驗證

這裡由於驗證可能是複數所以使用 ICollection

然後陣列可以當作 ICollection 的實體

再來就是中二到不行的抽象類 Judgement

之所以不想命名成 validation 之類的只是因為不想跟其他欄位驗證的類別混淆

並非因為這個傢伙

或這個傢伙

審判的細節靠子類實作

至於實作的細節平常怎麼幹就怎麼幹囉

隨便貼一個

觸發審判的方式也沒什麼特別

就在 Buster 裡面挖個方法觸發的時機高興怎樣就怎樣囉

這邊是在 Buster 放個 IsAllInnocent 屬性取得該屬性時會觸發驗證

該死的 Click 事件獲得了欄位驗證並且避免了重度脂肪肝

Great Success

標題梗 again

2014年5月4日星期日

ASP.NET Web Form 對應優先設計 (Mapping-First Design) 第二彈 - 百變星君

繼第一彈之後現在再來玩些變化

因為世上無可能有網頁全部都只用 TextBox 的

在 CheckBox RadioButton DropDownList 參上之前先來看看先前第一彈留下了什麼伏筆

1. 神手會失誤庸手會失憶

每次都必須宣告 ValueMapBuster 變數然後在 Page_Load 裡面 SetUpValueMaps Mapping 機制才會奏效

但是神仙打鼓有時錯每次都要 Key 這些固定 CODE 實在讓人 KEY 肚藍

所以我們需要把這些給西封裝起來放到基底類裡面

再靠抽象方法約束後人必須實作 SetUpValueMaps

2. 噁心的人形蜈蚣代碼

什麼是人形蜈蚣代碼?

something like...

or like...

咦好像沒什麼不對呀?

這樣寫的確沒有任何錯誤程式依舊能跑

但是這是一個造成難以維護的壞味道

如果哪天條件增加減少了勢必要到處去修改這些蜈蚣

況且這麼多的判斷式如果只是為了 "其中一種狀況" 發生的時候該做什麼 "對應的事" 的話

其他的判斷式在這裡就顯得有點擋路

所以我們需要善用多型

首先把原本的 ValueMap<T> 變成抽象類

GetValue 和 SetValue 則依靠抽象方法實作 GetDefaultValue 和 SetDefaultValue 的細節 (就是原本蜈蚣的部分)

再來就是 "多型" 的部分原先 Mapping 的時候需要考慮各種控制項的可能

現在則是每種控制項增加一個獨立的類別並且繼承 ValueMap<T> 來實作細節

這裡又會遇到一項設計上的考量有時候某個值不見得只靠一種控制項就能表現

最顯而易見的就是 RadioButton

一群的 RadioButton 實際上只對應某個欄位的列舉值

所以分成單體跟群組兩種類型的 Map 來應付

單體

TextBoxMap：預設 Map Text 屬性