The release (1.0.8) fixes a… strange… design decision that I made, to force the field type (and not the field value) to implement a specific interface.

Now you can define your fields as ICollection<T> and it will work as long as the value is EntitySet / EntityList / EntityDictionary etc.

Did you know that JBoss is now offering NHibernate support? It came up during several of my recent projects, along with my life expectancy . ("What happen if you get hit by a 747* ? ")

I talked with a couple of the guys there, and they were very nice and professional. That they can purchase support seem to have eased some of the fears of going with a non Microsoft route considerably.

* That was after I assured them that I'll survive getting hit by a bus J

Okay, this is a lame title, but my company (We!) is now hiring developers.

You can check out about the company here.

If you are a developer in Israel*, and you can follow the code that I usually post here, we will want you J

Give me a call at: 052-548-6969 or email me (orene J we-can.co.il).

By the way, this offer is not timed limited, if you see this post half a year from now, do give me a call. We always need good people.

 Some updates to this message:

Yes, unfortuntely we don't have a english site.

The main requirement is that you will be a good developer and like what you do.
Prior knowledge is certain technologies helps, but not mandatory. If you are good, you can learn.

That said, a passionate kid that show up with a burning desire to learn and some knowledge in Pascal that he got in high school will probably not be accepted.

We are a Microsoft shop, and nearly all development is done in .Net (C#). We are doing projects ranging from data warehousing to enterprise applications to backend components. (BTW, if you are a good VB programmer, we will welcome you in.)

If you are a regular reader of my Blog, you probably fit (if you weren't you would have stopped reading :-) ).

Just a tidbit, when I was hired, I never used SQL Server . And I currently in charge of data access implementations in several projects (all of which are using SQL Server).

* If you want to work with us from outside of Israel, give me a call, and I'll see what I can do.

The question came up today, how expensive it is to create objects in .Net, and is it worth keeping them in the cache if we can just as easily reconstruct them?

I wrote  a tiny program (attached) to check this issue. This program merely construct an employee instance using a typical constructor which accept the object's initial values.

The code is shown below, but I wanted to talk about the results first:

The times here are in minutes : seconds . milliseconds . Each point in the graph is greater than the previous one by one hundred thousand objects. As you can see, to create 5,000,000 objects it takes less the two and a half seconds.

So I wouldn't particularly worry  about instantiating objects (this doesn't include objects that holds scarce resources , like database connections, of course).

The overall test create 127,500,000 objects and took less than 1 minutes and 9 seconds.

Here is the code. It is ugly, but it does the job.

A couple of days ago I posted an idea about how simple it is to create an MVC framework on top of ASP.Net without affecting much of the development model. Since then, I got a chance to play with it a bit, and I'm surprised at what I found.

First, the tests were done using Web Application Projects, since there isn't even a point to start doing this in Web Site Project (although the implementation that I have right now will work there as well).

Ideally, what I would have wanted to do is to reflect over all the pages that implements a certain interface, IView (to be original) and add them to the IoC container, then when a request come in, I resolve it to the proper controller based on the URL, and the controller gets is view (the page) from the container.

The problem is this, there is not easy way to get the type of the page object from ASP.Net. The pages themselves are compiled the first time that they are request (simplified), so there isn't a good way to handle it except use GetCompiledPageInstance(), and this ties me back to the paths on the HD.

I suppose that I can write some component that will find all the .aspx files in the directory, and register them, but this looks really clunky to me.

Right now I'm using strings based approach, somewhat similar to the way MonoRail is working, and I inject Hashtables to the view. The problem with this approach is that I lose all the strong typing that I could get if I could get the interfaces to work.

Comments?

Most programmers had to implement a Hashtable or a map at some point (usually at school). Hopefully, they never do it again, but gain valuable insight about how the collection works.

In .Net, there are two methods that each object implements which are used with hash tables. Those methods are GetHashCode() and Equals(). When you create your own classes, you get the default behavior, which is to check for object reference equality (to the C/C++ guys, that is pointer equality).

The problem starts when you want to provide a different semantic for  Equals. For instance, if you have a range, and you want to say that if both items are the same, they are equals. So you override Equals(), make the appropriate check, and you are ready to go. [1]

First, a Hashtable is composed of buckets, like the ones of the left. A bucket has key and value, although in some cases, it has several key / value pairs.

Well, the Hashtable calls to the key's GetHashCode() method, divide the resulting value with the current capacity of the table. It then takes the remainder and check if there is already a value in the bucket.  If there is, it will double its capacity and try again[2].  Usually if there is a collision (two different keys with the same hash code), both of them will be put into the same bucket.

How does it pull the values out, then? Well, it is actually a lot simpler than that. You give the Hashtable a key and ask for a value. It calls the GetHashCode() method on the key, get the remainder from division with the capacity and then it knows in which bucket to check.

Remember, a bucket may contain more than one key, and even if we limited ourselves to a single key per bucket, it is entirely possible to have two keys with the same hash code. Therefore, the Hashtable will call the Equals method on the two objects. It will continue to do so on all the keys in the bucket  and find one where Equals() return true. If it can't find any key where Equals() is true, it will return null (or throw).

Do you see now why it is so important to implement Equals() and GetHashCode() together? And why it is crucial that objects that are equal to one another will return the same hash code?

If objects that are equals to one another do not return the same hash code, the Hashtable will look in a different bucket and will never find the correct key.

It is also important to remember that you may not want to put your objects as keys in a Hashtable, but there are plenty of others that will. Many frameworks uses Hashtable to add additional data to an object, which they can later access and act upon. Breaking the Equals()/GetHashCode() assumption will cause nothing but trouble, and it is one of those bugs that are extremely hard to find. Mostly because it is extremely non-obvious.

That said, you don't need to start implementing Equals() and GetHashCode() on all your objects, only on those where reference equality functionality is not enough. In the example above, a range is equal if the start and end are equals, and the hash code is simple adding the hash codes of the start and end.