通過服務插入與數據庫訪問

Question

我現在正在使用的代碼需要插入一堆相關記錄以導入外部數據。

有大量的代碼使用CustCustomerService插入數據，然后是一小段使用表記錄插入和更新其余代碼的代碼。 我曾向我的同事詢問為什么這兩種不同的方法以及答案是，當他開始工作時，他聽說通過服務方面的服務會更好，但是服務並不能支持他需要的所有更改，因此無法進行轉換。

我自己對此進行研究，只看到描述如何使用服務以及不同服務如何不同的信息。 但是沒有信息可以將它們與語言數據庫訪問進行比較。

所以。 為什么要使用服務而不是直接插入和更新記錄呢？

編輯：我必須澄清。 對於數據庫訪問，我的意思是：

smaServiceObjectTable sob;

sob.clear();
sob.Foo = Bar;
// ...
sob.insert();

Answer 1

我想到的兩個主要技術原因是：

1. 商業邏輯
2. RecId的

AX保持RecId編號順序，因此您永遠不要執行插入操作， 更重要的是，使用插入/更新服務可以使您和其他人運行業務邏輯。

因此，想象一下用戶決定購買每當記錄被更新/插入時與客戶進行交互的第三方ISV ...在直接SQL中會如何發生？

如果用戶后來想要一些邏輯來驗證客戶帳戶上的任何更改時如何驗證客戶帳戶上的CreditLimits，該怎么辦...他們將如何可靠地知道使用直接SQL更改客戶的方法？

RecId通常用作外鍵，並且還具有代理鍵的功能。 Direct SQL不能輕易/可靠地維護那些規范化的關系。

RecId序列存儲在一個表中，但也被緩存，因此除非您真正知道自己在做什么，否則不容易拉出下一個。

然后以@ FH-Inway所說的為基礎，當新的開發人員進入畫面時會發生什么。 該開發人員將必須弄清楚之前編寫的任何定制SQL。 這些服務也具有更高的可重用性，並要求更好的實踐。

編輯：為了響應您在帖子中所做的編輯，您是在談論通過X ++與AX中的表進行交互，而不是與實體服務或類似服務進行交互，而不是直接使用SQL。

我認為這是與場景有關的事情，很難寫出一個全面的答案。 該服務方法允許一個中央界面，當您有多個活動部件時，該界面可以提供一致性和其他驗證。 您可以將其視為類似於復制和粘貼相同的10行代碼，或將其封裝在可重用的方法中。 這樣，當您要更改這10行的功能時，只需修改方法即可。

因此，對於某些實體（客戶/地址/供應商/等），如果可以確保其他所有業務邏輯都被使用，則使用服務是有意義的。

在很多情況下，與表進行交互是非常有意義的。

我可以舉一個很好的例子，如果您要創建一個新客戶。 如果使用該服務，則只需提供名稱，地址，信用額度等，它將創建該服務並運行相關的業務邏輯。 如果您嘗試將新記錄插入CustTable ，則可能不記得要分配PartyId ，而使用該服務會自動為您完成。 當您創建將由服務負責的新客戶時，可能還會有其他基礎表自動填充數據。

另一個示例是在InventTable創建一個新項目。 基礎表InventItemInventSetup ， InventItemPurchSetup和InventItemSalesSetup可能需要在執行InventTable.insert()時可能忘記創建的記錄。 因此，這就是為什么在內部使用服務也更有意義的原因。

Answer 2

因為服務使您可以直接將AX與其他系統集成（至少在理論上如此）。 如果直接插入和更新記錄，並且想要將其與另一個系統集成，則必須自己實施集成。

是的，自定義AX服務可能很麻煩，但是根據要求，與完全從頭編寫集成相比，它仍然可以節省很多精力。

當然，如果您只是在導入時未集成到另一個系統，則自定義實現可能會更容易。 但是在那種情況下，我建議您看一下數據導入/導出框架（DIXF）。