App services: Why copy persistable objects?

When creating an App Services, a microflow is required as an input. It is only allowed to take a non-persistable object. As a result we end up creating a whole model of non persistent objects and copying objects in there. Why is this necessary? Error with persistable entity: The type of parameter 'List of MyFirstModule.AS_Account' is persistable. This is not allowed in app services.
1 answers


App Services are a step on our roadmap towards modularity in Mendix. To promote clean interfaces between modules, we have made a choice to only allow transient (=non-persistent) entities for app service types.

We know that in many cases the user has extensive structures in their domain model, with a lot of interconnected persistent entities. If such an entity is exposed, all it's dependencies will be rebuilt in the project of an app service consumer, including database tables for each database type.

We want to avoid that; and a way to do that is 'enforcing' transient entities for app services. That being said, we realize that this can be cumbersome for a designer of app services (but it is better for the app service client). We are thinking of a way to simplify the 'interface' extraction in the domain model.

In the next Mendix 5 release, we have made one exception to the rule of transient objects: FileDocuments. FileDocuments are persistent by design; and we have connected them to app services. Including Images and other generalized FileDocuments.

regards, Pieter