0

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

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

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

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

编辑：我必须澄清。对于数据库访问，我的意思是：

smaServiceObjectTable sob;

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

2 回答 2

3

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

  1. 商业逻辑
  2. 记录的

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

因此，想象一下，用户决定购买一个在更新/插入记录时与客户进行交互的第 3 方 ISV……直接 SQL 会如何发生这种情况？

如果用户稍后想要在客户发生任何更改时对客户帐户的 CreditLimits 进行一些逻辑验证怎么办……他们如何可靠地知道哪些方法会通过直接 SQL 更改客户？

RecId 经常用作外键，也有代理键的特点。直接 SQL 不容易/可靠地让人们维护那些规范化的关系。

RecId 序列存储在一个表中，但也被缓存，因此除非您真的知道自己在做什么，否则仅拉下一个并不容易。

然后以@FH-Inway 所说的话为基础，当新开发人员出现时会发生什么。该开发人员必须弄清楚之前编写的任何自定义 SQL。这些服务也更具可重用性，并强制执行更好的实践。

编辑：为了回应您在帖子中的编辑，您谈论的是通过 X++ 与 AX 中的表交互与与实体服务或类似的东西交互，而不是直接 SQL。

我认为这是一个取决于场景的事情，很难写出一个全面的答案。服务方法允许一个中央接口，当您有多个移动部件时，它可以提供一致性和额外的验证。你可以把它想象成复制和粘贴相同的 10 行代码，或者将其封装在一个方法中以供重用。这样，当您想更改这 10 行的运行方式时，只需修改方法即可。

因此，对于某些实体（客户/地址/供应商/等）而言，如果可以确保命中其他所有业务逻辑，则使用这些服务是有意义的。

很多时候，与表格进行交互是非常有意义的。

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

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

于 2017-06-28T14:47:06.433 回答
1

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

是的，定制 AX 服务可能会很痛苦，但根据需求，它仍然比完全从头开始编写集成更省力。

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

于 2017-06-28T14:31:48.807 回答