So ... for those of you using some type of ORM ... how do you handle multi-tier applications. Or a (REST) server which has to pass the classes to a client through JSON. Is that doable using some form of ORM? Or is that out of the question.

So ... for those of you using some type of ORM ... how do you handle multi-tier applications. Or a (REST) server which has to pass the classes to a client through JSON. Is that doable using some form of ORM? Or is that out of the question.

Also ... if you're using an ORM, feel free to let me know which one you use and maybe also why you chose that. Currently looking into a few alternatives including TMS Aurelius and the Devexpress Entity Framework. I know there are a few more alternatives on the market, but I have absolutely no idea why I would choose one over the other. So any feedback on that topic is more than welcome.

Comments

  1. Using an ORM is easier imho, since you abstract the queries. In TMS Aurelius you can simply add an extra condition to all your queries like Add(Linq['CustNo'] = 5) without having to deal with raw SQL. For REST server, our Aurelius-integrated TMS XData has server-side events that serve the same purpose, for any request for entities, for example, you can add custom filters in the Criteria (or of course implement your own custom code): http://www.tmssoftware.biz/business/xdata/doc/web/onentitylist_event.html

    ReplyDelete
  2. I use TMS Aurelius and TMSXDATA: very good product. Thanks Wagner!

    ReplyDelete
  3. I can see an ORM being used on the server side, but then the question is how do you handle it on the client side? Since when you update stuff on the client, there will not be any real persistence and you will have to send the data back to the server which will store everything. Hopefully you are able to use the same classes then

    ReplyDelete
  4. kbmMW has an ORM. Unfortunately I haven't had a chance to try the ORM part yet, but have been using kbmMW as the middle tier for 12 years in a professional (meaning it's real world app, in use by a professional businesses, not a demo app) app that's n-tier. I absolutely love kbmMW. There's a learning curve, but once you "get it", it's an awesome product. One of my clients is on Google's 1 gig service in Kansas. I can connect and use the app from Minnesota, and it is be hard for me to tell that it's not running on my local network! Point being, when using the binary transfer option its smoke'n fast!

    ReplyDelete
  5. Stefaan Lesage I have used ORMs for long (and still use them) but what you are talking about is not tied to ORM itself. You are actually saying your model can't be shared across server and client. This often happens and it is quite natural IMHO. The usual strategy here is to use a DTO (Data Transfer Object) in order to mediate two different object model (one for the server side and one for the client side). In MARS, I use Delphi records as DTO (pure value "objects") and you can use whatever you prefer on the client and server side (datasets, ORMs, whatever...).

    ReplyDelete
  6. I use mORMot, and it does the object transition through the tiers transparently.

    ReplyDelete
  7. kbMMW has both ORM and N-Tier support, so you can either, use ORM as Local support for embedded databases or ORM fgor ClienteServer, plus lots of addons like RestFull Apps, Cypher, encription. take a look at:

    http://www.components4developers.com

    ReplyDelete
  8. mORMot for the win. Free, fast, multi-platform and we'll supporter by A. Bouchez

    ReplyDelete
  9. Stefaan Lesage Regarding client-side usage, XData is transparent and you can use all entities and DTO's and service methods. What you implement/declare server-side can be (optionally) reused server-side. You can use/manipulate the client objects in memory, bind with visual controls using AureliusDataset, or even save data in local database and replicate data with server later, using TMS Echo.

    ReplyDelete
  10. An advice, take from years working with DDD: on production code, never publish the ORM to the user API, i.e. never publish directly your business objects. Define some REST service on top of the business layer, using DTO (data transfer objects). Internally, inside the server, you may use an ORM, or direct SQL statements (especially with legacy code), over your business object. In a nutshell: don't start your REST service from the data, but from the usecases!

    ReplyDelete

Post a Comment