Our boss is asking us some questions concerning the architecture of this software:

http://www.allegrodev.com/ - http://www.allegrodev.com/

He's asking us if how do we compare the architecture used by that software w/c is SOA and ours w/c is Devforce.

Can we still consider Devforce as a Service Oriented Architecture even though we actually didn't need some services in order to communicate to one end to another?

If not, what are the advantage and disadvantage of using Devforce over a native SOA or vice versa or what's their similarities?

Thanks,

Von

 

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.

 

When you say smartphones and tablets are we talking about breeze here? or perhaps a website that is rendered on the smartphones?

Another questions would be, since we're coding like a 2-tier app in Devforce by creating some business rules classes that validates or perform some rules, is there a way in Devforce that we can expose those business rules classes in the outside worlds (may or may not be .NET clients) aside from creating a bunch of WCF service that wraps those classes? 

Thanks,

Von

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.