I was talking with a friend of mine last night, an experienced developer who's leading a team of guys building a large commercial enterprise application. We were just chewing the fat over data access and how we approach things differently - I'm a fan of the domain model and use OR/M for persistence - usually NHibernate, but my buddy was advocating the use of the Dataset.
Many of us are told that the Dataset is just evil incarnate, but that's not actually true - the Dataset does serve a purpose, just not one in an enterprise application with complex domain logic.
The issue with a dataset is that it's not representational of data, it merely contains it. Beyond the activity of querying data and performing straight forward operations, it requires additional components. Representing complex logic and interrelated business entities is harder than it needs to be.
A domain driven approach on the other hand, with entities representing data, provides more flexibility to describe your logic - for instance, a customer object will contain properties to represent itself, along with business logic for operations and rules that govern a customer object and it's relationships to other objects.
Does that mean that the DataSet is intrinsically evil? No!
Sure dataset's have their problems - amongst others, they enforce a database centric view of data and when they serialise they also serialise a description of the schema of the data resulting in a bloated payload (this can be disabled). Despite these problems however, for trivial systems, they can serve a purpose.
It's a matter of choice. Even for trivial applications I would advocate a domain approach, but that's my preference. For anything non-trivial however and for any enterprise system, I'd avoid the dataset.
No comments:
Post a Comment