我正在創建一個應用程序，該應用程序需要由內部網絡上託管的Web前端訪問，並且也作爲計劃任務運行。在我們的內部系統之外不需要訪問任何內容，並且一旦應用程序啓動並運行，我們就不會想象在一段時間內會發生任何變化。Web服務或DLL？
我最初的想法是創建一個封裝大量必要功能的DLL，然後通過Web Forms界面手動執行以及作爲自動（每日）計劃任務運行的控制檯應用程序調用它。
另一個建議是將Web服務公開爲核心功能，但由於應用程序永遠不需要由外部資源調用，所以我認爲實現Web服務所需的額外工作可能不值得麻煩。 DLL解決方案也應該快得多（？）。
我的問題是你會選擇哪條路線？有沒有我沒有涉及的優點/缺點？任何明顯的遺漏？
免責聲明：我是.Net的新手，但由於我們的一位開發人員捲入嚴重事故，因此我被要求加強工作。
就我個人而言，我說去與DLL。這將是快速和簡單的。
使用Web服務時，您需要考慮網絡，防火牆和性能等因素，這也使得調試更加困難，因爲您無法從客戶那裏訪問Web服務，您將必須在呼叫的兩端設置斷點。
Web服務的另一個問題是你需要更強大的處理失敗。使用DLL時，您知道調用方法會成功，但使用Web服務時，您需要爲每次撥打電話時撥打電話失敗或超時做好準備。
最後，如果您在以後發現需要Web服務，您應該能夠很簡單地將DLL轉換爲Web服務並進行最少的改造。
你說得對，網絡服務有很多麻煩，而且速度慢很多。 我建議 - 做一個PONO（普通的舊.net對象），但使用接口。研究Spring.NET框架 - 它可以將這個對象作爲任何類型的（web）服務導出，因此您不需要執行此類操作。 在客戶端，您也可以使用spring來執行依賴注入，並通過更改配置文件中的值來決定是否要進行進程內DLL或Web服務實現。另外Spring還有Quartz調度程序集成，你可能也想看看它。
就我個人而言，我會做你說的;把我的邏輯放在DLL中。然後使用您的應用程序中的DLL，webservice以及將來要確定的界面。
現在有沒有需要創建一個web服務。你只需要在服務器上維護其他IIS服務。如果你稍後創建一個需要該DLL的接口，你可以簡單地引用它。所以沒有必要做到預防。
使用DLL是一種正確的方式，它速度更快，它可以在將來使用這些dll（如果需要）創建webservice並提供更高的web服務安全性。
我們確實需要更多信息。它很難回答，只知道你的要求是什麼。分層方法（dll /獨立類）簡單而快速。分層的方法（Web服務）可以讓您擁有一個環境，併爲您提供更多的抽象。無需更改客戶端，即可更改Web服務背後的代碼。
但爲了評估這個，我們需要知道你的項目是什麼，這個DLL會做什麼。否則，你只是聽到人們的偏好。
將您的邏輯封裝到Assembly中將足以滿足您的解決方案的需求，因爲看起來沒有任何東西會離開您的域的邊界，您的內部應用程序都將使用您設計的組件公開的功能。
出於可維護性的考慮，您可以很容易地從URL加載該程序集，並且如果此組件需要封裝到Web Service中（當然可行），然後您的代碼可以創建Web代理類最小代碼更改。
我正在開發一個類似的應用程序。我採取的方法是在dll中提取我的提取邏輯。這是通過web服務暴露的。我發現Web服務更簡單，因爲我不需要在客戶端上刪除接口或公開我的對象（我使用類來封裝數據）。然後我有web開發人員和winforms開發人員編寫自己的表示層。雖然有優點和缺點（不會進入他們）Web服務更簡單，因爲我有一個單一的圖層。使用遠程處理，我需要額外的接口或客戶端庫，必須安裝在每個客戶端上。這樣，我只管理服務器端，而不同的GUI是獨立的。我只是喜歡鬆散的編碼。我們運行了許多也使用web服務的windows服務。我們是信用卡組織，我們與衆多系統進行交互。 Web服務提供了最大的靈活性。
畢竟，它歸結爲您的個人喜好，考慮到您的要求。我會說，不要選擇1而不考慮以最小的努力進行更改的能力。我發現rad應用程序可以快速更改，並不斷添加新的要求。花點時間，讓你的項目和需求的範圍和壽命更加一致。然後發展到你的長處。
哇哇。他們都共享一個數據庫？如果是這樣的話，不，不，不。如果數據庫不共享，那麼它肯定是DLL。
正確的選擇是Web服務。原因也很簡單。
1）領域模型和業務邏輯的一致性。比方說，你在列中存儲枚舉，並添加一個枚舉並部署到一個應用程序。現在它將打破其他兩個應用程序。
2）易於部署。一個更改=一個部署。如果它是一個DLL，一個更改= 3部署。
3）DB事務和併發控制。在一個應用程序域中更容易解決它。
至於其他人建議，我覺得他們太偏。
1）跨應用程序域調試存在困難。您應該通過WSDL發佈可能的異常作爲錯誤異常。調用客戶端也應該適當地處理這些錯誤異常。在呼叫客戶端和服務器上設置單元測試和模擬也非常容易。斷點不是調試和使用分佈式應用程序的正確方法。你可以，並不難。我只是不相信這是正確的做法。
2）性能。 WCF允許您通過配置設置不同的綁定。從基本http（更易於調試）一直到命名管道，您可以使用它來獲得接近本地的呼叫性能。這個決定可以（幾乎是有幾個不同綁定的怪癖，你需要考慮），也可以在開發之後決定。
3）安全性。說WCF不處理安全是非常錯誤的。
最後，真正的缺點來自我：
1）更復雜。同意。不同的上下文使應用程序設計更加困難這有兩種方式。這種複雜性強化了層次的清晰分離。演示文稿應保持在演示級別的位置。
2）需要更多計劃。爲WCF Web服務設計合同本身就是一門藝術。
3）配置的管理開銷。對於新開發者來說可能會很艱鉅，但我希望你能快速克服這個障礙。 WCF配置是一把雙刃劍，功能強大但複雜（對某些人而言）。
我個人的經驗是，任何時候數據庫都被共享，並且這個DLL被用於多個應用程序域，我很遺憾，我沒有足夠的重視開發團隊去使用Web服務路線。
那麼你的最終決定是什麼？現在已經四年了。
我不能相信接受的答案是，你勸使用DLL的一個...
「我們沒有任何設想改變了一段時間。」
這就是爲什麼我們必須花時間修復由開發人員做出這些決定所產生的問題。不要只想今天，想想明天。數據庫的東西應該隱藏在客戶端，如果你必須添加一個新的客戶端，並明天一個新的？建立合適的合同和使用服務，網絡與否。
我想這是問題發佈的時間。只要看看這個類似的問題，答案就是Web服務。 http://stackoverflow.com/questions/7877916/web-service-vs-dll-pros-and-cons – 2012-10-10 05:27:05
是的 - 這有點necro。當時WCF不是問題。 DLL是我們去的方式，應用程序已經開始生產了4年！ – 2013-01-07 14:49:53