我與財務應用程序的工作，我期待爲我的設計應用的最佳解決方案。最佳asp.net WCF應用設計
我們的大多數/所有的業務邏輯位於存儲過程100的。我們有使用Web服務軟件工廠（http://servicefactory.codeplex.com/）構建的WCF Web服務項目。我們已經爲幾乎所有東西（表格，下拉等等）構建了存儲過程，並且這些存儲過程中的每一個都有自己的Web服務，這些Web服務暴露給Web應用程序調用。每個Web服務都是一個非常簡單的方法，它使用Web服務的確切參數調用存儲過程。
我也不太清楚，如果這是最好的設計和想問的建議和方案的設計。
別人也有類似的環境？它是如何實現你的目的？
這之間的經典折衷：具有體積小，集中服務，做一兩件事，一件事只有
一般來說，我會說我寧願方法＃1 - 保持你的服務好，小，易於維護，並尊重單一責任原則 - 一服務（或課堂）應該做一件事，一件事只有東西。
您可能可以將幾個邏輯上屬於同一個服務的呼叫合併成一個服務，但只要有太多的呼叫（超過10？15？20？），它就有一個趨勢讓笨拙，最終不得不因爲它處理這麼多的任務，去改變它過於頻繁....
我的看法是基於什麼打算使用的服務 - 他們打算服務器外部應用程序或意味着消費僅在您的應用程序中？
對於內的應用程序的使用，我傾向於去有一個進程健談層，而不是一個徹頭徹尾的過程層（例如，服務層做CRUD任務等）。從性能角度來看，前者是非常好的，並且通過使用多個Web服務器等仍然可以進行擴展。同一個進程內層可以託管多個前端 - 例如用於應用程序UI的Web應用程序，執行日常工作的控制檯應用程序WCF第三方消費的服務等等。事務管理和流動的上下文信息在進程內層可以很簡單 - 雖然它可能與WCF服務層一起使用，但它非常昂貴。
對於外部消費者來說，WCF服務非常重要，但是服務接口應該是笨重的，並且必須嚴格按照商業術語公開功能（例如，它不應該有用於持久性的CRUD方法，而應該包含從域 - 說CreateOrder，將創建條目到多個表）。