Breeze.Sharp or DevForce?

Two great IdeaBlade products for client application development in .NET.

They share the same data access patterns and terminology. Client applications fetch complex, interrelated business objects (“entities”) from a remote server via flexible LINQ queries that can filter, sort, project, and page data. Query results are cached on the client. Entities maintain their own change-state, raise property-changed notifications, and validate with custom and built-in rules. Changes can be batched and sent to the server as “change-sets” where they are processed and validated before storage in a database … all in a single transaction.

How do you choose?

Here are some of the reasons our customers prefer one product to the other.

Why DevForce:

  • We already use DevForce and have no mobile device requirements in the near term.
  • We prefer a WCF SOAP service; HTTP is not an option.
  • Some/all client devices are on an internal LAN with direct access to the server.
  • We control the technology end-to-end, server as well as client.
  • We need specific features in DevForce that are not in Breeze.Sharp (see below).

Why Breeze.Sharp:

  • We have an existing app with an outdated front-end. We need the quickest path to a modern, competitive UI that doesn’t change our existing backend business logic and services.
  • The server/client communication must be HTTP.
  • We have no or limited control over the server and its technology stack.
  • The database isn’t relational; we don’t use an ORM.
  • The client application must run on a mobile device (Windows, Xamarin on Android or iOS).
  • We might need an HTML/JavaScript browser client and want to minimize the implementation differences. between native and JavaScript versions; both clients should talk to the same server.

Here’s a partial list of the most prominent technical differences between these products.



Talks to any HTTP remote service running on any technology stack fronting any data store.

Talks to a DevForce WCF service (the “business object server”, AKA BOS) running on a .NET server, relying on Entity Framework to manage data access with a relational database.

Cannot talk directly to the DevForce BOS

Can only talk to the DevForce BOS

Same service-facing API as a BreezeJS client. App development APIs parallel the BreezeJS APIs.

Conceptually similar to BreezeJS but not API compatible.

Distributed (n-tier) client applications

Two-tier and distributed client apps

Desktop and mobile .NET clients (including Xamarin)

Desktop .NET clients only (WinForms, WPF, Silverlight, Windows “Modern” / “Metro”)

Asynchronous service calls only

Synchronous and asynchronous service calls

Save change-sets, $batch save to REST endpoints, or make individual PUT/POST/PATCH/DELETE requests.

Change-set save via SOAP call to a DevForce BOS endpoint.

Navigation properties are loaded explicitly or indirectly via expand query.

Can also lazy load navigation properties

No query caching; non-local queries always go to the server.

A query can be satisfied from cache if it was issued before (“cached query”).

Cache and remote queries are distinct

Combines remote and cache query results automatically by default.

No custom property interceptors (yet)

Supports custom property interceptors