這個問題是從一個Web應用程序引發的,儘管它也適用於其他類型的應用程序。我正在使用MVC。我有兩個應用程序代碼(模型,視圖,控制器,窗體,幫助器等)和庫代碼(外部庫和內部庫與自編寫的數據庫映射器,JSON轉換器等)。庫和應用程序代碼之間的區別?
我想知道你通常在哪裏繪製應用程序和庫代碼之間的界限(當兩者都是內部編寫的)?
某些庫代碼獲取的是特定項目,但仍有點抽象。
這個問題是從一個Web應用程序引發的,儘管它也適用於其他類型的應用程序。我正在使用MVC。我有兩個應用程序代碼(模型,視圖,控制器,窗體,幫助器等)和庫代碼(外部庫和內部庫與自編寫的數據庫映射器,JSON轉換器等)。庫和應用程序代碼之間的區別?
我想知道你通常在哪裏繪製應用程序和庫代碼之間的界限(當兩者都是內部編寫的)?
某些庫代碼獲取的是特定項目,但仍有點抽象。
庫的代碼旨在可重用,應用程序的代碼通常不是。當代碼不與應用程序專門綁定時,將代碼保存在庫中。
疑問時試圖回答這樣一個問題:如果我寫另一個應用程序
,將這段代碼保持?
我的一般經驗法則是:任何可能會在另一個項目中使用的東西,並且可以很容易地不依賴於任何特定於應用程序的代碼(並且有各種應用程序)圖書館。所以如果它可能重用,它會進入一個庫。
當面對這些分類問題時,我想知道一件事:錯誤分類的後果。
這段代碼是「庫」,代碼是「應用程序」......這種區別的好處是誰的好處?如果我們把一些代碼放在錯誤的類別中會發生什麼?
一個可能的答案:
它會影響代碼的重用。讓我們假設我們有一個策略:庫代碼在一個帶有所需頭文件的DLL中可用。應用程序代碼只是部署在.EXE中。
把一個很好的例程用於在應用程序中進行困難的計算,而不是在庫中,那麼它不容易被重用。
也許更進一步的東西來自這一思路......適用於版本控制的問題。我們是否需要製作更好的文檔? [即使只有一個開發人員,我們可能會更加小心謹慎嗎?]我們是否需要外部化配置信息,雙倍確保不要硬編碼任何東西?