I have been writing about some things related to Programming Inside Out while here at VS Live!  Last night I had a couple of good conversations with some vendors in this product space. 

First I talked a bit with DevExpress about their XPO product.  Currently it is the only OR Mapping product I know of that follows the Inside/Out rule.  Instead of starting with the DB and helping you map it to your objects (it does that too) it will create and update a database for you based on your objects and their relationships.  I plan to give it a closer look soon. 

The second vendor I talked with was Versant.  They not only have an OODB, but also an OR Mapping tool for .NET.  They have been in the business for several years, so I am confident we will be hearing a lot more from them.

I am glad we are seeing more companies playing in this space.  Issues of object versioning and various integration challenges will continue to be worked on to improve OODB options.  Will we see then end of the relational database anytime soon, probably not.  And, that is perfectly fine.  The most exiting thing for me is the increasing support I am seeing for Domain Driven Design concepts and tools.

I had the privilege of meeting Jimmy Nilsson today in the speaker lounge.  He did a talk on Domain Driven Design today at VS Live.  It was good introduction to the concept.  I had hoped it would go deeper, but in 1 hour it is hard to cover much.  After my exploration into Business Objects earlier this week with Rocky I was curious about Jimmy's recommendations for persistence with the private fields problem I mentioned before.  In short the answer was that nHibernate uses reflection to address the problem.  He acknowledged the performance costs.  

I guess it just brings out the reality that as solution architects we have to balance performance and maintainability and choose wisely.  I know that most of the things I work on can afford the impact of reflection and it will not be problem.  Today I am back with thinking that the best approach for Domain Design will include a service layer that handles the interaction with the persistence layer.  So, when I use the CSLA framework I will move the Data Portal code to separate classes and find a way to integrate my favorite best practices for persistence and object creation.

I has the pleasure of presenting today.  I promised everyone in the session that I would post the sample code and slides so have at them: VSLive.zip (3.22 MB)

I feel honored to be part of this lineup.

I made an exciting discovery today in the vendor hall at VS Live.  SoftWIRE is here and I stopped by to talk to them about their tool.  I ran across it a couple years back when I was looking for tools to help teach my kids programming concepts.  They have a library of controls for programming Lego Mindstorm robots among many other things.  Now that the toolkit is free you can all afford to pick up a Mindstorms kit right!  I asked about some books to help me get started teaching the kids and what do you know they now have some teacher and student guides included with the SoftWIRE software.  I am looking forward to giving this one another look and getting my kids and others interested in programming.  I think I will stop back by their booth and pick up a few extra CD's for the user group.

Thanks SoftWIRE!

After lunch yesterday I continued the session on OO with Rocky.  I really appreciated the practical aspects of his presentation.  It is obvious he has been striving for OO purity and landing in the real world.  That is a difficult thing to do, but so often necessary.

Fro example he said that Tiers are bad.  He was speaking of physical ties in the architecture.  The obvious problem with Tiers include the deployment issues and performance issues.  The trade offs include scalability, fault tolerance and security.  At Idaho Commerce and Labor those of us doing more Object centric development have realized how painful it is that we are running on a web farm.  If the user sessions were sticky or we we running on a single front end box then we could use caching and working with object graphs would be smother.  So, I definitely understand and agree with Rocky that Tiers are bad.  I have also come to believe that many solutions would be best run on a simplified physical architecture.  So often more energy and money is put into redundancy than it would cost to have a hot spare standing by with instructions for staff on how to switch it over.  Of course there is no perfect one size fits all solution.

Another thing that struck me was Rocky's belief that using serialization is bad practice for persistence.  To clarify he was not talking about an in memory working set, but for long term storage.  Serialization is necessary for passing objects around, but has significant challenges when it is used as a more permanent storage mechanism.  The biggest problem is versioning.  Say you store an object and then have a need to modify the class by adding or removing properties.  Then you try to deserialize your stored object for version 1 of the class using the schema of version 2 of that same class.  OOps!  There are ways to deal with the versioning issues, but Rocky's opinion is that its not worth it.

I was impressed with the CSLA Data Portal concepts as they are similar to many of the ideas I have been considering in the past.  Primarily I like the concept of a single port of entry for storing and retrieving objects. 

My conclusion is that I want to use the CSLA framework.  It has been well tested in the real world.  Well improved since the book was printed.  Actively used in the community.  Strives for purity, and lands in reality. 

Only 1 major complaint I have and I need more experience to decide where to land.  Love to have feedback from others on this.  In the CSLA framework the Data Access methods are contained within the Business Object Classes themselves.  The pattern I prefer places the Data Access in its own classes.  I like to have a Manager class or service class has responsibility for persistence.  I asked Rocky about it and he is happy with his solution of course.   The reason is private members.  The only way to persist and retrieve private members is if you have access to them which means you are either inside the class or you are using reflection.  Reflection is expensive and much more difficult.  As I think about the purpose of private fields I realize that they certainly can and do exist without a public property accessor.  Also, the encapsulation of of property into a private field allows for some behavior in the Get/Set blocks.  Often you would not want that behavior to happen if you are merely recreating an object from a data store.  If the Object itself represented data and not behavior then it be much less of an issue.  Of course understanding Rocky's presentation that objects should model behavior and not data helps me to clearly understand his framework decisions.

Take a look at the ASP.NET 2.0 Membership system.  It uses the static Membership class for persistence and creation of MembershipUser.  This doesn't fit Rocky's model because the business object of Membership user is not responsible for its own persistence.  I like it much better though because the behavior of persistence is modeled separately than the behaviors around the authentication object. 

Anyone care to share their thoughts on this?  Is it a case or purity meets reality?  Perhaps some Objects best fit the CSLA model and others a different model?

Recently I gave a presentation to my co-workers at Idaho Commerce and Labor on programming inside out.  The core concept was on designing objects around use case.  I stressed the need to forget the database, not because data is un-important, but that is must not drive design.   Similarly the UI must not drive the application design.  Rocky is fully backing up that concept in his pre-conference talk.

I am not 1.5 hours into Rocky's presentation on Building Distributed Object-Oriented Apps.  Here are the bullet points I have noted so far:

• Objects are defined or modeled by behavior, not data
• Objects consolidate behavior, not data
• Don't do relational data modeling of objects
• Code re-use is a myth (at the business level, not at the framework level)
• Help out the UI developers with support for things like undo, data binding and broken rule tracking
• Data should only be owned by a single application (SOA concept)

There was also a discussion on the difference between approach a framework with base classes versus interfaces.  I will leave that research for you to do on your own.  There are important considerations for each.  Understand the options and chose appropriately.

To be continued....

This morning I got all checked in.  Hotel was nice and close.  First time at VS Live.  First impression is that this show is much smaller than shows like Tech Ed and PDC (my favorite).  It looks to be similar in size to a Connections conference, but probably a bit larger.  I will have a better feel later.

Found out Bliz will not make it.  Bummer.  He is moving to Florida and will be sorely missed!

This time around I am not only an attendee, but also a speaker.  I am excited about the opportunity to be presenting at the show.  In the future I hope to do that more, but probably on some very specific topics I have not seen others cover.  I will not give anything away yet.  So if you want to catch my talk on security, its on Tuesday at 2 PM in the ASP.NET track.

Off to get filled on building distributed apps with Rocky Lhotka.  He just said datasets/datatables have a home.  Backyard in the doghouse.  Go get 'em Rocky!

So, here I am in San Francisco preparing to attend and speak at VS Live this week.  So in order to make sure everyone is well fed and networked I will list the evening activites here as I run accross them.

Dear INETA board members, speakers, user group leaders and liaisons, volunteers, and distinguished conference guests

Please join us for the INETA Rendezvous at VSLive! San Francisco

An informal get-together during the conference

Monday, 7 February 2005
8:00 pm until whenever

Room Pacific H, 4^th floor
San Francisco Marriott
Fourth Street at Mission Street 

Great company — Open bar — Hors d’oeuvres

Hosted by the Microsoft Western Region Developer Evangelism Team