比方說,我有這個User
類:Dapper:是否可以自定義特定類型的特定字段的類型映射?
public class User
{
public int ID { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string Email { get; set; }
public DateTime DateCreated { get; set; }
public DateTime LastLogin { get; set; }
}
,我想要映射下表:
CREATE TABLE "user" (
"ID" int(11) NOT NULL AUTO_INCREMENT,
"FirstName" varchar(45) DEFAULT NULL,
"LastName" varchar(45) DEFAULT NULL,
"Email" varchar(255) NOT NULL,
"DateCreated" int(11) NOT NULL,
"LastLogin" int(11) NOT NULL,
PRIMARY KEY ("ID")
)
或被置於簡單的話:我想將日期時間屬性存儲爲int字段在數據庫中。但是,這是這個類/表的情況。其他類/表可能映射不同。我正在考慮將自定義轉換函數與類型或成員地圖結合使用。
是否有可能用Dapper實現這一點,如果是這樣的話?
這樣比較好 - 我希望這是這種類型的「普通」映射,在這種映射中使用了它的查詢。我想使用Dapper,因爲我想依賴數據訪問對象中的本地SQL控制應用程序級別,而非存儲過程。 我總是將datetime映射爲整數,除非我有充分的理由不這樣做,因爲將datetime對象映射到MySQL中的sql datetime類型時出現臭名昭着的時區不匹配錯誤。 維護我的代碼的人是一位知道我住在哪裏的心理學家。儘管他並不擁有斧頭。 –
@AmirAbiri沒有違法意圖,但TimeZone不匹配錯誤是程序員的錯,而不是ORM。將所有內容存儲爲UTC並計算顯示器的本地時間,並且可以避免任何數據源中的問題。如果您唯一的理由不是關注時區,請將您的日期時間存儲爲日期時間。 – Haney
沒有采取 - 程序員錯誤是我想要避免的。作爲架構師,任何設計的考慮因素之一就是開發人員是否或多或少都有錯誤傾向。 我不是在責怪ORM,我只是試圖以某種方式使用它。以UTC存儲所有內容並對其進行精確控制*完全是我想要自定義轉換功能的原因。無論如何,重點不在於進行哲學辯論 - 我們可以同意不同意。問題是這是否可以與Dapper一起使用? –