Home/ Questions/Q 8754165
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T13:34:03+00:00

I am looking at OData and it is very powerful, at the same time

  • 0

I am looking at OData and it is very powerful, at the same time it’s very disconcerting. It is the equivalent of exposing your datasource to a remote user. There is no service nothing nada and very little injection points, resulting in an almost comical 2-tier architecture.

My concerns are:

  1. It’s hard to enforce pattern such as DDD while using OData.

  2. It is also hard to use OData against a set of soa Data Transfer Objects, because these are not usually queryable. ie.by the time you get the DTOs, the DB query is done, but OData is just starting up. There is not a lot of value in querying against it, because the DTOs are already in memory.

  3. I can create a view on the DB itself that’s a representation of the OData entity, but this is putting UI concern in persistence. Big no-no.

  4. At best combining the result set from various DDD services now happens at the UI layer using kludgy javascipt – a maintainance nightmare with poor reuseability record.

  5. Another possibility is to write a translator for the OData entity which is likely a ViewModel level class, that then translates to the DTOs, that then translates to Domains, that then translates to the ConceptualModels, the rest the ORM can handle. But this will require an inordinate amount of resources.

In short, how do you make OData play nice with SOA, OO encapsulation principles, DDD and just good old SOC?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There needs to be clear separation of the OData standard and the OData implementations.

    As for the standard:

    The standard itself to my view lets you to have an OOTB accessible data endpoint with full metadata on a portable manner. With support for relations and projection consumers can compose viewmodels on the server or later on the client. It is important to note, that OData supports operations (functions) to be exposed, so on the top of automatic crud you can have remote methods that seamlessly integrate into the relational pattern (functions can have results that you can further query, still on the server, and also functions can act as the “smart writer” code).

    To wrap it up: OData gives a shape to what actually happens most of the time when someone needs massive REST compliant data access: formalizes common, always repeated scenarios like how it is to query for data or submit data back. This might be still affected by what you write at point 4, but to my opinion it’s not an OData related issue. This is simply how AJAX and Mashups work: you’ll have a client with lots of code dealing with combining data.

    Other issues of yours can be answered with selecting the most appropriate server implementation. There are a couple of implementations already:

    • EF4/EF5 + WCF Data Services being the most “automatic”. In this use case you might just be correct regarding some of your concerns but: with the fine extensibility model of EF you can interact with the automatic operations as you wish. Having an application that is driven by the actual EDMX model is a true DDD scenario.

    • ASP.NET Web API let’s you have a totally code based back-end for what you perceive as a static, relational endpoint, so this is where you can think in 3 layers: DB, middle tier to bridge between DB data and to what is best for the clients, and client tier as a smart consumer to that model.

    • JayData provides these in Server Side JavaScript with the added dynamism of JavaScript.

    • SAP NetWeaver gateway exposes complex SAP data on a manner easy to consume for simple scenarios.

    OO concerns:
    With V3 of OData we have now “instance methods” (that are definitely server methods too) so what actually SOA took away with brutally separating things to data and functionality OData really gives back: defining functionality + data encapsulated but in mapped to the SOA concept of static methods with context data that act like the "this".

    2Tier concerns:
    IMHO 2Tier architectures became “ancient” not because the client has too much knowledge about the server side structure, but because they did not scale well and the new thin cliens were to dumb to act like a real DB client. In fact 2tier was always easier to work with (from a developer point of view), and now that actually OData server implementations are indeed middle tier with logic, you actually can get the best of both worlds:
    – code agains a virtuall 2 tier architecture
    – and scale as a normal n tier application can.

    • 0