Devforce as SOA

 

Having said that, the sweet spot of DevForce are rich clients. The power of the EntityManager comes to fruits when directly used on the client. Traditionally SOA architectures have thin chatty clients, because everything is a service that lives remote. Performance is often a problem.

 

Rich clients on the other hand leverage the device, cache data on the client and execute logic on the client against the cached data and only incur roundtrips if additional data is needed or changes need to be persisted . This generally leads to better performing apps especially with mobile devices such as smartphones and tablets where the connection to the services can be brittle, or Internet connected devices in general where as the service provider you don't have control over the bandwith and the quality of the connection.

 

As far as exposing business logic to the outside world goes, if the client technology is different from the server technology you have no other option than implementing the logic twice. For example in case of Breeze with a .NET back-end. 

Where the client technology is the same as with DevForce you can architect things such that you can share the business logic. The way to accomplish this is by separating the loading/saving from the actual logic that operates on the data in cache.

Unfortunately, the answer to this question comes down to who you decide should suffer. The developers having to implement and test the logic multiple times or the end-user with slow application performance. I personally side with the end-user. The end-user should have the best user experience possible and the developers should pay the price to implement it. That's how Apple became successful with all their iDevices.