If you were to expose your business objects only through an interface (primarily method based for changing data, and getters), without letting consumer code reference the implementation, then it wouldn't be so bad.

But... I agree with you. Microsoft could have done better.

Why not do it the same way we do serialization? That seems to have solved the public/private issue.

I think, the interface is the right way, but another way as you said.
if the SPOIL fill the object thru an explicit interface (or get the parameters from there) these would not be seen if you access it the normal way. so they are just "hidden". i think thats an fine solution.

I have attempted to implement this solution sort of. Not using stored procedures but I am building Sql queries with parameters. I ended up using reflection to view the private variables and created a couple of attributes to be able to rename/uninclude fields from being used. The only issue I ran into was that in this case, there are some private variables I want to set directly and some public properties I want to set for reasons of business rules. Other than that, I don't really write any Sql access at all. It's pretty neat stuff. The only way I have thought of to deal with the field/property set is to check if the PropertyInfo.HasSet is true. Only thing is, I have to stick to a naming convention bewteen the field and property so they can map. Kind of cheesy but I could take care of that as well with a custom attribute. Writing the Sql is one of the most boring and necessary parts of creating a project and MS could have done much more to take care of this!

Rocky,
I was just curious to know whether you have looked at NHibernate at all as a tool for providing a generic ORM/DAL in conjunction with CSLA?

It seems from the investigation work we've done so far that it allows you to preserve your object model and also eliminate the need to write all the SQL/SPs as part of the project itself.

It also works against fields, rather than properties.

Any thoughts?

[Another really bad thing about this approach is that it means your object's data would be exposed in an unprotected manner through this interface. How much do you trust your fellow developers? Your UI developers? Are they _really_ going to avoid the temptation to bypass your business logic and use that other interface? If the object seems "hard to use", but becomes "easy to use" through the interface, which way do you think they'll go?]

One way to bypass that issue is to utilize the StrongNameIdentityPermissionAttribute on said interface members. An imperfect solution but easy to use if you tend to release only strongly named assemblies (IMHO a good idea regardless of GACing).

As a BSP (blatent self promotion) we've also created a GDN community aimed at enhancing and running with the SPOIL concept. Anyone wishing can find out more information here: http://www.gotdotnet.com/Workspaces/Workspace.aspx?id=d70f8668-bb98-4270-9f0f-ba166776f3ac

What surprised me the most about SPOIL is that it's exactly what I published way back in August 2002 in my MSDN Magazine article [1] titled, "Dynamically Bind Your Data Layer to Stored Procedures and SQL Commands Using .NET Metadata and Reflection"! Heck, even the class names and some of the comments have remained the same. I guess they just took off from where I left and added a few helper methods to run the commands, but I think it's just the wrong approach. I deliberately never provided any helpers for executing the commands because it's a different problem space althogether. You want to help in fabricating the command objects and that's it (do one thing, do it well and leave the rest to upper layers or subsystems). Let the caller decide on what to do with the commands, how to execute them and what to do with the result sets. You don't want to assume the caller wants ExecuteScalar, ExecuteNonQuery or ExecuteReader. May be someone just wants a DataSet by connecting a command to a data adapter and then doing a fill? With ADO.NET 2.0, you might be interested in asynchronous execution. What about stored procedures with multiple result sets? Or event XML with ExecuteXmlReader? The point is, you simply can't satisfy all combinations with providing a hundred overloads. Something case will always be forgotten.

The work that I originally published in the MSDN Magazine article was a precursor to DBMethod [2] in which I solved all of the problems I mentioned at the end of article. From a design stand-point, you might be interested in checking out the discussion "A Design Pattern for Data Access Methods" in the introductory article on DBMethods [3]. Even with all the helpers, the real problem that SPOIL doesn't go out to solve is reduce the time needed to define signatures for the 200 stored procedures in your database and then keeping them in sync. This is something I addressed with DBMethods by reading SQL metadata and generating signatures for VB.NET or C#. This can be done using a command-line tool or a Visual Studio custom tool for an integrated experience. DBMethods also internally uses runtime MSIL generation to contain the cost of reflection to initialization-time only. Anyway, I don't want to turn this into a plug or anything. My point is that something like SPOIL and SPOIL+ are not adding much value. The "transform your code from an object-orientation to a relational paradigm and back " is the wrong problem statement and therefore falls short on the promise. It would have been simpler and more right to say that you just want to reduce all that boilerplate code for setting up command objects by making database stored procedures appear like methods from managed world. Finally, by making sure that you never execute the generated command but just return it, you don't need to provide integration with DAAB, EntLib or what have you. The SqlCommand is the lowest common denominator between all libraries, including well, ADO.NET!

[1] http://msdn.microsoft.com/msdnmag/issues/02/08/NETReflection/default.aspx
[2] http://www.raboof.com/Projects/DBMethods
[3] http://www.raboof.com/Projects/DBMethods/Introduction.aspx