This now works :-)

The challenge is still open, I intentionally stopped before completing the feature, and there is a failing test in the RecusriveMocks fixture that you can start from.

And just to give you an idea about what I am talking about, please run this and examine the results:

svn diff https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk -r 1682:1683

A really cool web view of them is here.

I have just committed a change to the way Rhino Mocks handles expectations for dynamic mocks and stubs.  Previously, the meaning of this statement was "expect Foo() to be called once and return 1 when it does":

Expect.Call( bar.Foo ).Return(1);

Now, the meaning of this is: "expect Foo() to be called one or more times, and return 1 when it does". This means that this will work:

Assert.AreEqual(1, bar.Foo);
Assert.AreEqual(1, bar.Foo);
Assert.AreEqual(1, bar.Foo);

Where as previously, using dynamic mocks, it would fail on the second assert, because the expectation that was setup was consumed. I think that this is a more natural way to behave, but this is a subtle breaking change.
You can get the old behavior by specifying .Repeat.Once().

Thoughts?

I was asked to comment on the use of DB schemas, so here it is. The first thing that we need to do is decide what a schema is.

A schema is an organization unit inside the database. You can think about it as a folder structure with an allowed depth of 1. (Yes, just like MS-DOS 1.0). Like folders in the real file system, you can associate security attributes to the schema, and you can put items in the schema. There is the notion of the current schema, and that about it.

Well, so this is what it is. But what are we going to use if for?

People are putting schemas to a lot of usages, from application segregation to versioning. In general, I think that each application should have its own database, and that versioning shouldn't be a concern, because when you upgrade the application, you upgrade the database, and no one else has access to your database.

What we are left with is security and organization. In many applications, the model layout naturally fall out into fairly well define sections. A good example is the user's data (Users, Preferences, Tracking, etc). It is nice to be able to treat those as a cohesive unit for security purposes (imagine wanting to limit table access to the Accounting schema). It is nice, but it is not really something that I would tend to do, mostly because, again, it is only the applications that is accessing the database.

Defense in depth might cause me to have some sort of permission scheme for the database users, but that tends to be rare, and only happen when you have relatively different operation modes.

What I would use schemas for is simply organization. Take a look at Rhino Security as a good example, but default, it will tack its tables into their own schema, to avoid cluttering the default schema with them.

In short, I use schemas mostly for namespacing, and like namespaces elsewhere, they can be used for other things, but I find them most useful for simply adding order.

I decided to take a look at what I would take to implement static proxies (via Post Sharp) in NHibernate. The following is my implementation log.

• 09:30 PM - Started to work on post sharp interceptors for NHibernate
• 09:35 PM - Needs to learn how I can implement additional interfaces with PostSharp.
• 10:00 PM - Implemented ICollection<T> wrapping for entities
• 10:35 PM - Proxy Factory Factory can now control proxy validation
• 11:15 PM - Modified NHibernate to accept static proxies
• 11:28 PM - Saving Works
• 11:35 PM - Deleting Works
• 11:50 PM - Rethought the whole approach and implemented this using method interception instead of field interception
• 11:58 PM - Access ID without loading from DB implemented
• 12:01 AM - Checking IsInitialized works
• 12:13 AM - After midnight and I am debugging interceptions issues.
• 12:15 AM - It is considered bad to kill the constructor, I feel.
• 12:16 AM - No one needs a constructor anyway
• 12:30 AM - Realized that I can't spell my own name
• 12:34 AM - Resorting to Console.Write debugging
• 12:40 AM - Wrote my own lazy initializer
• 12:42 AM - Realized that we can't handle lazy loading without forwarding to a second instance, need to see how we can capture references to the this parameter using PostSharp.
• 12;45 AM - I think I realized what went wrong
• 12:55 AM - Lazy loading for non virtual property references works!
• 12:57 AM - Constructors are back
• 12:59 AM - Lazy loading for calling non virtual methods works!

The first thing that I have to say is wow Post Sharp rocks! And I mean that as someone who is doing AOP for a long while, and has implemented some not insignificant parts of Castle.DynamicProxy. Leaving aside the amount of power that it gives you, PostSharp simplicity is simply amazing, wow!

The second is that while things are working, it is not even an alpha release. What we have right now is, literally, one evening's hacking.

What we have now is:

• Removed the requirement for virtual methods
• Removed the requirement for set to be an instance of Iesi.Collections.ISet<T>, now you can use ICollection<T> and HashSet<T>.
• Probably broken a lot of things

Consider this a proof of concept, as you can see, it takes time to implements those things, and currently I am doing it at the expense of time better spent sleeping. I started this because I wanted to get relax up from a 12 hours coding day.

If you have interest in this, please contribute to this by testing the code and seeing what breaks it. There are a bunch of TODO there that I would appreciate a second pair of eyes looking over.

You can get the code here: https://nhibernate.svn.sourceforge.net/svnroot/nhibernate/branches/static-proxies

Note that you need to reset the project post build action to where you have PostSharp installed.

Oh, and I left a joke there, see if you can find it.