Folks,
I have a BO that calls a DAL layer class to handle the db access.
In the BO, I have a property Version, that is type int.
In the DAL class (autogenerated), the Version property is type SqlInt32.
IF I try to use the DataMapper.Map functionality, in the CSLA SetPropertyValue, I get a fail because it can't implicity convert SqlInt32 to Int32 (or vice versa, depending on which way I am mapping).
Any ideas here rather than doing the:
_this.Version = Convert.ToInt32(dal.Version);
and just manually mapping everything?
Any way to use an implicit operator definition to map SqlDbTypes to the .Net types so that the Datamapper works?
Thanks
I realize this is not necessarily funny, but your post brought a smile to my face.
The reason is that ADO.NET does have the ability to convert to/from these types. So if your DTO were generated with .NET types, and loaded from a DataReader (which is unavoidable at some level) then ADO.NET would have solved this for you.
It just goes to show how, in an attempt to abstract things away, we often accidentally hide or eliminate pre-existing solutions to problems. We're so busy hiding/encapsulating ADO.NET that it is easy to forget just how powerful it is.
Unfortunately I don't have an easy answer for you. To my knowledge you can't tap into the SqlDataReader's type conversion functionality without using the SqlDataReader. And I won't hard-code SQL types into DataMapper at any point, because then I'd be stuck hard-coding type mappings for every database on the planet.
What I will likely do in CSLA 3.5 (once I get 3.0 done) is apply some serious effort to making DataMapper more extensible using various design patterns. This will include some technique by which you will be able to override the way values are converted to/from the BO - much like the ValueConverter concept used in WPF. Not much help now I know, but data stuff is my clear focus in 3.5.
Thanks Rocky -- I actually DO use that functionality, but it turned out the auto-gen tool that we use set all of the properties to be Sql data types instead of .NET datatypes (which clearly the DAL should have for abstraction purposes). We are redoing the auto-gen templates to fix that, and then I can hopefully use the mapper class!!
I DO however like the idea of making the DataMapper extensible to allow a bit more flexibility/customization! I'm using the 2.1 framework at the moment, and while it has taken some time to get my head around it, it is working out great for the architechture of the project!
Copyright (c) Marimer LLC