我在我的web應用程序中使用三層體系結構。我正在編寫所有與數據層相關的MS SQL Server數據庫代碼，現在需要從Excel，CSV和其他電子表格文件中讀取大量數據。我使用OleDbConnection，OleDbCommand，OleDbDataReader來讀取用戶上傳的電子表格文件中的所有內容。有關我應該在哪裏編寫所需代碼的爭論，在業務邏輯層或數據層？我的假設就像從從電子表格中讀取與我們的MS SQL Server Db沒有任何關係，所以我想將它寫入業務邏輯層。在業務或數據層中編寫邏輯
這是正確的決定嗎？有什麼想法嗎？
我寧願爲什麼不在解決方案中爲聯合數據訪問層構建多個項目。理論上講，您仍然會設計一個三層體系結構，但代碼差異性高，可管理性和可伸縮性。這裏的建築樹看起來怎麼樣：
我敢肯定，這將適用於您的架構。
數據層。其實它仍然是一個數據流。你應該把它當作 你的業務層通常不應該知道數據來自哪裏。
從數據源中提取或保存數據的最佳選擇是在數據層中實現它。然後將這些數據傳遞給業務層以應用業務邏輯/業務規則。保持數據訪問&存儲對業務層透明。
一些好處： 1.這是爲了將未來的可擴展性分解爲可擴展性&。如果您需要將Excel數據源更改爲RDBMS或任何其他類型的文件，則無需更改任何業務邏輯。只有數據訪問邏輯會改變。同樣，如果您需要添加更多業務規則或刪除一些業務規則，則不需要更改數據訪問層。 2.如果您需要合併來自兩個數據源的數據，那麼您可以輕鬆地對業務層透明化
爲什麼不在業務層中抽象化兩個數據源並使用合同？這將使其可測試並獨立於數據層。 – abatishchev