||jb43081 wrote: We try to avoid datasets whenever possible.
OK, so we're on opposite sides of the DataSet fence, but that's fine.
We use DataSets because with our product (mentioned above), we don't need to write or maintain any data access code. Changes to the data model involve changing the DataSet and the database, and everything in between takes care of itself.
Acutally, if you use a persistance framework, such as nHibernate, you don't have to write ore maintain any dalc code either, just the XML based mapping file, which is much lighter (in memeory) than a datastore.
Sure, you may take a slight performance hit for using DataSets over custom business object classes, but rapid development and ease of maintenance seemed to outweigh that hit in my mind.
Can you give a bullet point or two about why you avoid DataSets?
Well, for me it comes down to this:
Datasets take more system resources than using domain objects that are able to manage their own storage.
With nHibernate you can write one save, one load and one delete method in you base class. You create a mapping for each domain and that's it, your done! (OK, 99% of time, that's it.)
Conceptually, my thinking is that a domain object should be able to manage it's own persistance state without having to rely on an object or structure like a dataset. To me, it's just cleaner architecture.
Now, that's not to say that I never use dataset. They are hand for things like if I need to retreive my data and export it as XML. But, for just simple CRUD, I don't see the need for the added overhead.
And by the way, I'm a J.B. in 43081 too
Send me an email
offline, since I may know you, or someone you know.
Lol! "WESTERVILLE IN DA HOUSE!"