I split my data access out into a separate assembly. By doing this, not only am I ensuring that only the DAL assembly has references to DB-specific assemblies. Pplus, we all know how MS loves to throw new data access technologies out there, so this gives an easy way to only modify that area of the code. In general, I like how this approach has worked.
Here's the problem, though. If I want to pass (e.g.) my Customer business object to my DAL for insert, I need to pass all of the properties from the BO to the DAL. My thought was to use DataSet to do this, and since Rocky was kind enough to write ObjectAdapter, it seemed to make sense to use this to generate the DataSet. However, the ObjectAdapter only appears to do a shallow copy of the object.
What I think I need from the ObjectAdapter is:
* (Optionally) perform a deep copy of the Customer object so I get collection and object properties in related DataTables in the DataSet.
* Create a DataSetAdapter object that will take a DataSet and reconstitute an object so that I can use this obejct on the other side (i.e. on the DAL)
Am I missing something here, or does this seem reasonable? Any chance this is being considered for the next version of CSLA? Any other classes out there that do something similar?
Thanks much.
Dan Miser
Hi Dan,
I created ObjectAdapter for the very specific purpose of converting objects into a DataSet to do reporting. I never envisioned it being used as you describe, but that's a very interesting idea.
ObjectAdapter is loosely modeled on the ADO adapter provided by Microsoft - where you can use it to load a DataSet based on an ADO Recordset. That was my mental model for building ObjectAdapter.
DataMapper is somewhat related, and may be part of your answer in the long run.
I don't honestly plan to enhance ObjectAdapter over time - it does what it was intended for.
But I do plan to enhance DataMapper over time, because it is (in my view) just the first run at tackling the broader issue of reshaping objects into other objects in various ways. Being a believer in organic development, I built DataMapper to solve a couple immediate problems around Web Forms and Web Services, but with an eye toward other issues such as data access, etc.
That said, I don't have a timeframe for when I'll get back to DataMapper. I have a lot of irons in the fire at the moment as it is...
Always remember though, my goal in writing the books has never been to create the be-all-and-end-all of frameworks, but rather to illustrate the thought process using CSLA .NET as a concrete example. Where CSLA .NET comes up short, you should take the ideas and extend them to solve your problems.
In this case, you may want to create a version of ObjectAdapter that operates against fields instead of properties. And perhaps a version of DataMapper that can map from a DataRow into an object.
I always recommend creating these things external to Csla.dll itself - as modifying core CSLA .NET code just gets you in trouble as changes are made over time. But copying ObjectAdapter and DataMapper into your own project and modifying from there is safer. And that is fine from a license perspective, as long as you put a comment at the top of those code files indicating that they came from the Expert VB/C# 2005 Business Objects books by Rockford Lhotka.
Rocky,
One feature I'm really missing is that the DataColumns do not carry the type of the property/field. For the present, I have created another class with basically your code but in addition, data columns that include type information.
My concern is that I have not extended your code through object oriented design. What is your recommendation? Also, you mention in your post from 2006 that you have no plans to enhance the ObjectAdapter. Does that still hold?
Thanks,
-Anna
It is true that I don’t plan to do much, or anything, with
ObjectAdapter.
One solution may be for me to drop it from CSLA and contribute
it to CSLAcontrib, thus allowing those people, such as yourself, who use it and
need to enhance it to take it where you need in terms of features and
functionality.
I wrote it originally to fill a very specific purpose:
converting objects into DataSets to bind to Crystal Reports. These days all the
major report engines can bind directly to objects, and so that purpose is no
longer valid, and so a good argument can be made that it should be removed from
CSLA.
Rocky
From: anna
[mailto:cslanet@lhotka.net]
Sent: Thursday, November 15, 2007 8:43 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] ObjectAdapter enhancements
Rocky,
One feature I'm really missing is that the DataColumns do not carry the type
of the property/field. For the present, I have created another class with
basically your code but in addition, data columns that include type
information.
My concern is that I have not extended your code through object oriented
design. What is your recommendation? Also, you mention in your post from 2006
that you have no plans to enhance the ObjectAdapter. Does that still hold?
Thanks,
-Anna
Copyright (c) Marimer LLC