When I think of a .Net ORM mapper, things like Paul Wilson's OR Mapper, NHibernate, LLBLGen, etc. come to mind. Clinton made a presentation:
http://www.ibatis.com/downloads/SQLMapping.ppt in which he describes IBatis as "SQL mapping": mapping sql statements to things (entity objects, IDictionary, etc.). I've had limited experience with code generators like Code Smith and an old version of LLBLGen. My experiences with them have been very favorable when the project first starts out but as I need to add a field or tweak something later on I end up having to modify a lot of genearated files by hand. I suppose I could have tried re-generating code but I'm always afraid of loosing my small tweaks becuase I had to regenerate the entire DAL due to a NVARCHAR column changing from length from 25 to 50 characters. For someone who is familiar with SQL and doing ADO by hand, I think IBatisNet is just right in terms of letting me have control over the important things such as the queries are being sent to the database while at the same time saving me from having to write lots of boring code to bind parameters to/from IDbCommand and IDataReader objects. Features like the caching engine, sql statement logging via log4net, and dynamic sql are things that I never would have gotten around to if I had continued to write my ADO by hand. I don't know of a lot of other .Net data packages that make everyday useful features such as "cache this list of Address objects for 12 hours or until someone updates or inserts new information" so easy to turn on and off. A custom entity cache manager may be better in some circumstances but for the 5 or 6 lines it takes to add caching into a project, IBatis it can't be beat! The dynamic sql is exteremly simple to work with. No more coming up with TSQL hacks to create dynamic WHERE or IN() clauses. I'm find myself reusing (via the "extends" of the <statement> tag) a lot of commonly used sql fragments. Adding a new <select> statement is often as simple as extending the "GetMany" statement (with whatever JOINs it needs) and adding my own WHERE clause. The log4net support really ties everything together. There's no second guessing of what IBatis is doing. I've always know exactly what is being sent to (and one of these days, what's coming back from) the database. I've always felt uneasy with the way ORM mappers build queries on-the-fly. I understand the principal behind it but I still have some FUD (I bought the "Hibernate in Action" book to help disspell some of those fears) about what ORM mappers are sending back and forth the database. If I _only_ need one field from a table its easy to tell IBatisNet to give me back an int or a string or a even an IDictionary without having to populating an entire object. The clencher is that if I can't do something in IBatisNet, I still have access to underlying IDbConnection and IDbCommand objects to do things by hand. IBatisNet offers a lot of functioanlity but its also quick to get out of the way when I need it to. I cringe when I see projects bound to things like SqlCommand and OracleCommand. I'm working on a project now that started out as just a small 3 table Access database. It grew much larger, even spent a few days in SQLite, and is now on its way to Sql Server. The only real change to my code was changing the <selectKey> node within my <insert> statement*. Had I used a ${selectKey} property, I would have only had to make a change in my properties file. So if you haven't actually tried IBatis yet Kevin, I recommend you check it out at some point. My two cents... - Ron * - There were about 20 Jira issues between then and now :) --- Kevin Williams <[EMAIL PROTECTED]> wrote: > Larry Meadors wrote: > > > We have a consultant on site, and he is asking if we can get a > DataSet > > out of iBATIS... > > I've been lurking for quite a while without having time to really > *try* > iBatis.NET, but I use other Object-Relational Mapping tools daily. If > I > understand correctly, iBatis is an ORM solution. The idea is to work > with simple objects designed for the business domain. For example, > Customer, Order, and OrderItem. > > Both DataSets and mapped objects can be used similarly, but I find > myself doing more casting and such when I use DataSets. I can type a > Customer's name as a string and their zip code as an int, but if I > use a > DataSet I might have to cast them to the right type. > > ORM solutions also help me unit test more of my code base. I find it > easier that way, at least. It's not as easy with straight ADO.NET. > > Ask yourself, and the consultant, what are the trade-offs between the > two. > > Hope that helps! > > Cheers, > > Kevin > > ---------- > Scanned for viruses by ClamAV >
