Is strongly typed database code worth it? It's giving me a headache!
-
OK, I love to learn new and better ways to do things, but this just doesn't seem one of them. I'm originally from the Java camp so I've used straight DB code such as hard coded calls to the database and ORM tools like Hibernate. I've been working in VB for the past 5 years on various projects and have used similar techniques here as well. I am working on a fairly large project and decided to use strongly typed db access such as what is taught in these fairly popular tutorials: http://www.asp.net/learn/data-access/[^] Boy am I getting a headache. It seems to me that the only benefits I get are IntelliSense and compile time checking. IntelliSense wasn't available before strongly typed database code so this is more of a convenience than any real need. Compile time checking is nice but I've already had several errors that are not caught until runtime. These errors largely deal with enforcing constraints when filling a DataTable using a standard DataAdapter. Most of these errors are extremely trivial, do not interfere with my actual code and would never have been brought to my attention without strongly typed db code. So here is what I see as the major negative. I feel like I am getting much more code dependence rather than the current shift towards independence. This project largely works with data from a vendor database. If they ever update their schema (which can be as often as once a week) my app will break, even if they simply change a field from varchar(10) to varchar(12). I'm starting to lean towards either rolling my own db code or using NHibernate again. Also, LINQ seems to be a departure from this strategy as well. Does anyone else have any comments? Have any of you used strongly typed db code on a large project and found it to be indispensable? What am I missing? Thanks! Matt Penner -- modified at 17:13 Tuesday 6th November, 2007