How Do *You* Do Data Access in .NET?

We design our domain objects based on business entities, then we use nHibernate to map them to tables in the database. The objects are responsible for maintining their state.

Before nHibernate, we'ld created CRUD procs and use data readers to retrieve the objects and sql command objects to store, update and delete objects.

We try to avoid datasets whenever possible. [A]

jmbledsoe wrote:



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.

jmbledsoe wrote:

 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.

jmbledsoe wrote:

 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!"

Will do!

brentnewbury wrote:



I like to use simple queries DataSets to initialise objects. That way you keep your Object Orientation which may make it easier to adear to business rules.

Acutally, I think it's the opposite. To me, a domain object that can manage it's own persistance and not rely on an "external" object or service is more encapsulated than using a dataset. There are ways to take it to the nth degree. Certinally nHibernate helps with that since you can write one save, one load and one delete in your base class and let the mapping do the rest. Or, you could probably use a strategy patter to really abstract out the data access and it doesn't have to be tightly coupled.

One thing that I guess also rubs me wrong about this apporach is that to make the data store approach as effecient as you can you really need to do a shared one for all of your objects. So, you have this large shared object with business data in it that is also in your business objects now. That just seems "wrong" to me, the data should only live in one place. I can't think of which OO rule it would technically violate (and maybe it doesn't violate any of them) but it just doesn't seem "correct" to me.

brentnewbury wrote:

I don't really use an Object Relational (O/R) system. Although, I can see why people would, it effectively takes the burden of developing custom business classes of the system designers. You just need to make sure you get the correct object model in your database.

In general, I design in this order: front end, domain layer, database layer. Doing it this way you are ensured that your object model and data model (where it makes sense) are in sync.

Just my $0.02