In the spirit of open-mindedness and being willing to have my assumptions challenged, I will put it on the list to investigate and let you know my thoughts.

It may indeed be solving a problem I didn’t know I had

Thanks~!

Thanks for your questions.

Orasis is not different from other ORMs in achieving the same results i.e. database abstraction and mapping Objects to Databases. How it achieves that it is completely different. I would just say that while the rest are all frameworks with maybe some GUI to get you going, Orasis is not a framework! It is a database access layer development IDE that you use build and manage queries and mappings to your Objects (using refelection and query metadata). When you say “Build” it then calls its internal code generator to generate you pure ADO.NET code to achieve your mapping results. You can then use the code or the generated Assembly in your project directly. And what developer would not want the ability to actually run and test their DAL layer and mappings before calling them in their Application layer. The Orasis Mapping studio has a built-in tester to execute your code and sql and let you see your results before you even call it from your app.

A download is better than a thousand words. Try it and se for yourself. It is a database access development revolutionary technolgy!

Sorry, that reply (of course) was really intended for Adnan

The right tool (for data-access or any job for that matter) is the one that “makes simple stuff easy, makes complex stuff simple, and makes difficult stuff possible”. An ORM that provides you the ’safety valve’ of falling back to hand-crafted SQL or even (yes!) sprocs if/when you need them for the small percentage of times that the tool isn’t doing for you exactly what you need is absolutely the right choice (and its not a surprise to any reader of this blog that NHibernate does all of that!).

Besides, the world already has an OSS product that “maps SQL queries to objects”. Its called IBATIS (http://ibatis.apache.org/) and in case anyone is interested in pusuing this approach (which to be fair can be quite useful in certain cases), check out either IBATIS (java) or IBATIS.NET (.net) and dig into it– its a really powerful tool to have in your toolbox, but doesn’t rely AT ALL on any code-gen to get its work done. I’ve used it in the past for situations where a ‘traitional’ ORM isn’t appropriate/needed/possible and it works quite well for what it is/does.

Its not clear to me at all how Orasis Mapping Studio is an improvement on this already-existing (and quite mature) OSS project. If anyone knows the answer, please let me know.

I realize your post was just a product plug…but you know that most ORMs will allow to use your own SQL right? So just use the ORMs generated SQL until you need to eek out a little more performance and replace that one instance with your hand-crafted SQL. You could even use SPROCs *gasp* (sorry Steve).

So we wrote a layer that would take the SQL and hydrate our Objects directly through ADO.NET. We were kind of back to the basics, but we wrote a tool to do all the work for us and it generate us the code, and managed the mappings instead of writing another Framework or Layer. It was the ideal ORM solution our team was looking for. Things were finally manageable and under control. We got rid of all the configuration and mapping properites code that we had collected in the previous stages and just generated the code from the tool whenever our DAL needed work. The Objects became oblivious of their pesistance, and the generated DAL code acted as a service to read and persist Objects to fulfill specific business requirements and use cases.

You can go check it out at Orasis Mapping Studio

I actually think that your observations are indeed on-target. As your Domain Model digresses more and more from your relational model, the correspoinding disconnect increases and thus the effort needed to map the two back to each other (usually via an O/RM) can get quite significant.

If your database already exists in your application and you have good reason to radically diverge your Domain Model from the database, then a tool like NHibernate may not be the right one. IBatis (and IBatis.NET) is a tremndously powerful alternate approach that offers a much more flexible relational < --> object mapping experience than even Hibernate/NHibernate provides. If your Domain Model really bears *ZERO* resemblance to your relational model, then this might make more sense for your situation.

Its a spectrum though along which you need to decide on a target ROI and a solid cost-benefit target. Like all good software design questions, the answer is ‘it depends’ and its up to you to decide what’s right for your project, of course. But in general, yes, you can design yourself into a real corner if you’re not careful with developing a Domain Model in complete isolation from any idea about how it will be persisted.

Remember what I always tell people: just because your *objects* are persistent-ignorant doesn’t mean that *you* our your *design* should be too