Question

我现在正在处理的代码需要插入一堆相关记录来导入外部数据。

有大量代码使用CustCustomerService插入数据，后跟一小段代码，使用表记录插入和更新其余代码。我和我的同事询问了为什么两种不同的方法和答案是，当他开始时，他听说通过服务更好，但服务并不支持他所需要的所有改变，因此转换。

自己研究我只看到描述如何使用服务的信息以及不同服务的不同之处。但没有信息将它们与语言数据库访问进行比较。

因此。为什么我直接使用服务而不是直接插入和更新记录？

编辑：我必须澄清一下。使用数据库访问我的意思是：

smaServiceObjectTable sob;

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

Answer 1

两个主要的技术原因（我能想到）是：

商业逻辑
RecId的

AX维护RecId编号序列，因此您不应该执行插入操作，更重要的是使用插入/更新服务允许业务逻辑由您和其他人。

因此，假设用户决定购买第三方ISV，无论何时更新/插入记录，都会与客户进行交互......直接SQL会如何发生这种情况？

如果用户以后想要在客户帐户上更改任何内容时对客户帐户验证CreditLimits，那么他们将如何可靠地知道哪些方法通过直接SQL更改客户会怎么样？

RecId通常用作外键，并且还有代理键的功能。直接SQL不容易/可靠地让人们保持这些规范化的关系。

RecId序列存储在一个表中，但也被缓存，所以除非你真的知道你在做什么，否则不要轻易拉下一个。

然后，为了建立@FH-Inway所说的话，当新的开发人员进入画面时会发生什么。该开发人员必须弄清楚之前编写的任何自定义SQL。这些服务也可以更加重复使用，并强制实施更好的实践。

编辑：要回复您在帖子中的编辑内容，您谈论的是通过X ++与AX中的表进行交互，以及与实体服务或类似的东西进行交互，而不是直接使用SQL。

我认为这是依赖于场景的事情，并且很难写出全面的答案。服务方法允许使用中央界面，当您有多个活动部件时，可以提供一致性和附加验证。你可以把它想象成复制和粘贴相同的10行代码或将其封装在一个方法中以便重用。这样，当您想要改变这10行的运行方式时，您只需修改方法。

因此，对于某些实体（客户/地址/供应商/等），如果能够确保每一个其他业务逻辑都被命中，那么使用这些服务是有意义的。

很多时候，与桌子互动是完全合理的。

我能给出的一个好例子是你是否要创建一个新客户。如果您使用该服务，您只需提供名称，地址，信用额度等，它将创建它并运行相关的业务逻辑。如果您尝试将新记录插入CustTable，您可能不记得分配PartyId，而使用该服务则会自动为您完成。当您创建将由服务处理的新客户时，可能还有其他基础表会自动填充数据。

另一个例子是在InventTable中创建一个新项目。基础表InventItemInventSetup，InventItemPurchSetup和InventItemSalesSetup可能需要您在执行InventTable.insert()时忘记创建的记录。所以这就是为什么在内部使用服务也会更有意义。

Answer 2

因为服务允许您将AX与开箱即用的其他系统集成（至少在理论上）。如果直接插入和更新记录，并且想要将其与另一个系统集成，则必须自己实现集成。

是的，自定义AX服务可能很痛苦，但根据要求，它可以比从头开始完全编写集成更省力。

当然，如果您只是在没有集成到另一个系统的情况下进行导入，那么自定义实现可能会更容易。但在这种情况下，我建议您查看数据导入/导出框架（DIXF）。

通过服务和数据库访问插入

2 个答案: