代碼生成器與代碼重構

Question

你喜歡你的CRUD程序。代碼生成，框架驅動或手動編寫？

Answer 1

我的代碼生成器的經驗是，他們是一個好開始，但在更改結束後，我通常要手動重寫模塊。當然，這可能會成爲維護問題。但它真的變成了「多少繩子」問題。 哪個您正在處理的生成器，框架和資源？其中有些是可怕的處理，其他的工作是正確的。

Answer 2

如果您使用.Net使用Linq，那麼它很容易維護。 LinqToSql可以輕鬆更新數據模型，而無需更改代碼。

Answer 3

我喜歡框架驅動和手動編寫的混合。我用NHibernate和LinqtoSql做了一點，有時他們爲我生成的查詢需要一點幫助。

Answer 4

這真的取決於您的應用程序的大小。手工製作的數據訪問層對於非常小的應用程序來說是最有意義的，因爲您擁有最終控制權，但對於任何大中型應用程序，我都會推薦一個代碼生成器。我有APEX SQL（不是很好），LINQ和亞音速（都很好）的各種經驗。我即將評估一個Telerik ORM，但我想這也會很好。

Answer 5

在我看來，代碼生成器是壞設計的標誌，違反了DRY。作爲一個好的框架，你會保持更少的代碼。使用框架，您最終還會擴展並重構代碼，而不是代碼模板。

Answer 6

我喜歡代碼生成與以下原因自定義模板： 減少編碼工作 易使全球變化 模板嵌入架構，可確保開發人員遵從。 編碼錯誤的機會較少。 一致的功能 需要測試。

事實上，使用代碼生成器時，我能夠在架構更新後的幾分鐘內，使用60多個表修改數據庫來創建或重新創建存儲過程，實體類和DAL。通過使用自定義模板，我確保了所有層都符合我的命名規則，並確保正確的錯誤處理和防止雙重插入。

適用於固定價格合同。如果是小時，那麼你可能需要手工完成:-)

Answer 7

如果我需要使用代碼生成器，我喜歡將一個快速的Perl腳本放在一起生成代碼，所以我理解，框架是選擇之一究竟是什麼產生和爲什麼。

Answer 8

如果您將用戶視爲數據輸入員以維護您的數據庫表，那麼它們非常有用。它們有助於最小化滿足最低要求所需的編程時間。

如果您希望您的作品的質量能夠反映出比這更好的東西，那麼可以爲他們說的最好的方法是，如果您不太確定如何自己製作簡單的一致UI屏幕，它們可能會給您帶來快速啓動。

就我個人而言，我發現基於實際用例將它們重構爲有用和有吸引力的東西比從頭開始需要更長的時間。他們是迪爾伯特尖尖的老闆會喜歡的那種技巧。

Answer 9

我發現一個比代碼生成器更好的CRUD邏輯框架。當一組複雜的表生成了非常緩慢的查詢以產生結果時，我遇到了這種情況。