Service Portal (API/OData)

[kevind2000]

Any idea/guidance how to implement Service/API layer (OData, GraphQL, etc. ) using CSLA.NET Business Entity?

Could we generate OData Web Service Interface by reflecting CSLA.NET Business Entities?

[rockfordlhotka]

Years ago I looked into how one would build an OData provider over a custom object graph or data set. Not specific to CSLA, but for another scenario. It is really hard, at least if your goal is to support all the query, navigation, and other OData features.

I suspect that it is easier if you limit the features of OData you are going to support, and don't provide arbitrary query/navigation capabilities. Presumably return an error status when anyone attempts to use those capabilities?

So the short answer is yes, you can almost certainly do very simple cases by using code similar to what is in the DataMapper component. But to actually support OData is very difficult.

[kevind2000]

Appreciate your two insights.

One of the biggest benefits of CSLA.NET is to implement Business (Domain) Logic in one place, which can be run on the server, client, or both. With Blazor and .NET 5/6, CSLA.NET could be used to develop enterprise business applications over the Internet in a very productive way.

Back to many years ago, we might ship the Business Objects as SDK, that is, DLL, for third parties to reuse the objects/functionalities. To your second point, this would be tightly coupled - might be ok if both SDK and Client Applications could be updated in a controlled and synced way. Hence, we need introduce the Service Layer.

Naturally, the Service Layer should also be implemented through Business objects, since Service Interface is a gateway/contracts to Business functionalities - it would be providing almost same Entity Model and the flexibility to evolve the internal business objects implementation. At this point, having a Service Layer, like OData Web APIs, based on the Business Objects, is a logic step. To your first point, this would be hard to tackle in a dynamics/flexible way to support all the OData features, on the other hand, it would be tedious to create/maintain manually.

No wonder, most of existing Service APIs are intentional defined and manually developed.

[rockfordlhotka]

I strongly feel that the best answer is to treat a service API/endpoint as a type of "user interface" that just happens to be JSON instead of HTML. Which means defining and creating DTOs that act as message/data types for response and request data via the service.

Then you map the properties from those response/request types to your domain model, just like you would behind a UI, allowing the business rules to run and so forth.

Even with that model though, supporting OData over any arbitrary object graph (DTO or domain) is just plain hard work.

[kevind2000]

Agree, it's not an easy feat to map Object Graph from its metadata (e.g. through reflection) into OData model and to support all the features.

We have been doing DTOs and Response/Request for Service APIs for a long time, like WCF - it's defined by the Service Provider and lots of simple yet duplicate code to mimic the business object model for message contracts. And it's not flexible from Client/Consumer side. OData Web API changes this a little bit.

GraphQL changes Service APIs completely, which defines the service schema on the client side. Given the effort to implement OData Web API, we may just implement GraphQL based on Business Objects. OData Web API is so ubiquitous that we have no choice but to support it too - plain more work.

[rockfordlhotka]

Does OpenAPI (swagger) impact this at all? It seems like the way a lot of folks are going to provide metadata for consumers of services.

[kevind2000]

OpenAPI seems a RESTFUL API description specification - not much help until we have RESTFUL Service Layer on top of Business Objects.