2013-11-01 20 views
3

我很好奇從REST層服務的實體中分離核心域實體的首選方式是什麼。如何從REST域中分離數據核心域?

我在這個啓發性的Spring REST教程http://spring.io/guides/tutorials/rest/1/上看到,直接在REST層中公開核心域模型是一件好事,因爲它應該獨立於核心域模型而進化。

核心服務是處理和生產事件。這些事件被視爲應用程序的通信端口。核心服務沒有看到任何REST域實體。而REST控制器沒有看到任何核心域實體。

爲了使事情更簡單,讓我們考慮只有一個實體Order實體的例子。

本教程演示了Order REST域類如何通過REST請求傳遞給控制器​​。反過來,控制器創建一個傳遞給Order處理事件的OrderDetails實體,以創建一個CreateOrderEvent事件,然後將其傳遞給返回另一個OrderCreatedEvent事件的服務。控制器最終從返回的事件中創建一個REST域Order實體,並將其發送到響應中。

我們可以看到,對於這一個實體,核心域實體有一個類,REST域實體有一個類,事件有效載荷實體有一個類。另外,我們可以看到,坐在應用程序核心中的事件擴展了一些基本的事件,這些事件強烈地提醒了HTTP方法。看到這個REST就像滲透到應用程序核心中的東西,當我們試圖首先做的事情是將應用程序核心與REST層分離時,有點令人驚訝。

任何想到這個設計或一些替代設計?是否有任何實現這種解耦的首選方式?

感謝您的任何建議。

親切的問候,

斯特凡

一個額外的問題,我現在有...

我應該去實體NotFoundException異常或在事件notFoundEntity事件成員,一個REST域從數據域中解耦?

發送回控制器的事件可以攜帶可用於控制器的notFoundEntity成員狀態。

這裏是事件notFoundEntity邏輯:

protected boolean notFoundEntity = false; 

public boolean isNotFoundEntity() { 
    return notFoundEntity; 
} 

public static OneAdminEvent notFound(Long id) { 
    OneAdminEvent oneAdmiEvent = new OneAdminEvent(id); 
    oneAdmiEvent.notFoundEntity = true; 
    return oneAdmiEvent; 
} 

的服務更新取決於該實體的事件構件狀態已找到或沒有:

Admin admin = adminRepository.findOne(deleteAdminEvent.getId());    
if (admin == null) { 
    return AdminDeletedEvent.notFound(deleteAdminEvent.getId()); 

在控制器中,以檢查呼叫對於已找到與否的實體:

if (adminDeletedEvent.isNotFoundEntity()) { 
} 

這與符合去耦設計。

但是,我不確定解耦事件應該攜帶這些信息。這些信息可以被看作是一個例外,一個商業習慣例外。

此外,使用異常使得它可以指定在事務註釋回滾屬性:

@Transactional(rollbackFor = NotFoundException.class) 

有了一個例外,唯一沒有發現實體邏輯左邊是服務,事件不包含任何。

服務現在看起來像:

Admin admin = adminRepository.findOne(deleteAdminEvent.getId());    
if (admin == null) { 
    throw new NotFoundException("No admin was found with the id " + deleteAdminEvent.getId()); 

什麼憑經驗使用決定何時在事件中使用的成員國以及何時使用業務自定義異常?

+0

Iam不知道答案。但我曾經與openmrs這個醫療記錄系統合作過。 REST層中有一個與核心應用程序分離的獨立模塊。你可以看看它的設計。 – geekgugi

+0

@geekgugi謝謝,我會看看他們的REST層,它應該很有趣。 – Stephane

+0

他們正在使用彈簧AOP。 – geekgugi

回答

2

這個示例應用程序更難以更加分離REST域和核心域層。 REST(a.k.a.「view」)對象不僅與核心(a.k.a.「域」)對象完全分離,而且它們的直接通信也通過內部事件驅動體系結構解耦。核心事件如此強烈地提醒您HTTP方法的原因可能更多是由於示例用例的簡單性而非必要性或設計。這可能是例子的危險。 :)

雖然這確實是分層應用程序的一種很好的方式,但真正的問題是它是否需要適合您的特定場景。如果您的應用程序將非常面向數據(例如,業務規則很少的數據輸入系統),那麼您可能不需要單獨的一組REST域對象(很可能您決定不需要單獨的一層「查看傳統MVC應用程序中的「對象)。您可以採用Spring Data REST方法(請參閱Oliver Gierke的示例應用程序RESTBucks)。再一次,如果你在覈心中有一些繁重的商業邏輯,並且想要創建一個豐富的領域模型,那麼你可能更適合使用更多的解耦架構。

+0

謝謝,我想我並不需要那麼差才能解耦。我會看看RESTBucks示例。 – Stephane