商業邏輯應該去哪裏？

我正在使用將使用ASP.NET MVC 4 & SQL Server的Saas應用程序。我打算有一個數據層（使用EF5），一個服務層（可能只有RESTful服務），一個DTO層和Web UI層。後來，我打算將此應用程序擴展到移動平臺，對於Android & iPhone ...也許是Windows平板電腦。商業邏輯應該去哪裏？

通常，可以爲包含業務規則的域對象創建單獨的圖層。然而，在我的情況下，如果我這樣做，那麼我將不得不復制規則再次爲Android ...並再次爲iPhone。所以，我正在考慮在服務層本身中擁有業務規則。然而，無論出於何種原因，這都不合適。

對此有何建議？

來源

2012-09-21 Skadoosh

你爲什麼要複製android的規則？業務規則在域中，除非你談論「表示邏輯」。您應該有一個包含業務對象和相關業務邏輯的域圖層。然後其他層引用此。 – RPM1984

最初的所有內容都將以.net編寫。如果我在單獨的業務層中編寫規則，是否可以在Android或iPhone OS中使用相同的dll？ – Skadoosh

你能舉出一個你會在不同應用程序中執行的「業務規則」的例子嗎？ – RPM1984

表示層必須是它是什麼..只是表示層。你的商業規則不應該在那裏。我明白你的DTO將會是你的客戶端（android，iphone，web等等）的對象，所以不需要將你的業務對象轉移到UI。將您的業務層隔離在服務器端，讓您的客戶使用它來獲取他們需要顯示的數據。

我的建議是使表示層不知道業務規則。使用這種方法將使您的解決方案可擴展並易於擴展。是一種適用問題分離的好方法。

說出來..你可能會擔心如何在不同的平臺上分享你的DTO。我認爲最好的方法是不要用.NET對象提供表示層，因爲您打算在表示層使用不同的編程語言和技術。 JSON和REST可以很好地解決您的問題。我建議使用Asp.net Web Api來處理json對象。 Objective-c，Java和Javascript（用於Web UI）可以使用這種對象。

來源

2012-09-21 07:19:58 margabit

你說，你有一個服務層。業務邏輯應該落後於它。

Business layer -> (shared business objects) -> service layer -> (shared DTOs) -> presentation layers

其中表示層是MVC4，Android，IPhone等。它們都可以共享相同的DTO，但序列化方式不同。

來源

2012-09-21 10:11:33 jgauffin

從性能角度看，複製的規則爲每個平臺是去（因爲它分離不同的設備之間的處理），但是從維護性，一致性等角度來看，你應該把業務規則在工作流的方式，在服務層內/並行。

http://msdn.microsoft.com/en-us/library/ee658103.aspx

來源

2013-11-22 18:25:37 Dave

商業邏輯應該去哪裏？

回答

相關問題