On June 12 2008 we had our first Code camp for Sweden User groups here in Sweden.
We got about 60 visitors. And 11 speakers and some really nice topics.

Defensive Programming, Good Code, Silverlight, Enterprise Library 4.0 in practice, Error handling and much more.

The developers seem to like it very much and we will surely have more Code Camps in the future and hope for more volunteer speakers and visitors.

·          DeepZoom
1.        New file format completely XML based. Also, there will be a new Deep Zoom Composer tool that will allow you to create these new file types.
2.        MultiScaleTileSource  (implement a tile source to existing tile databases)
3.        Better notifications when sub-images enter the view

·          Controls
1.       New TabControl
2.       DataGrid improvements: Autosize, Reorder, Sort, Performance increase, and more
3.       Calendar now supports multi-selection and blackout dates
4.       Improved Templating Model: Visual State Manager
5.       Control properties changes (Background, Tooltip, FontFamily, FontSize…)
6.       Including controls in the runtime instead of having them packaged in app package

·          TextBox
1.       IME Level 3 input support on Windows and Level 1 on Mac
2.       Text wrapping and multiline selection highlighting in textbox
3.       Scrollbar Support
4.       Document Level Navigation keys

·          Improvements in error handling, reporting

·          Property System/Parser
1.       DependencyProperty.Register/RegisterAttached now supports PropertyMetadata
2.       DependencyObject.ClearValue
3.       Visual Tree Helper

·          Data Binding
1.       Per-binding level validation
2.       Support for element syntax for binding markup extension
3.       Binding to Attached Properties
4.       ItemsControl Extensibility (OnItemsChanged method)
5.       Fallback in Value Conversion (Binding.UnsetValue)

·          Input
1.       Limited keyboard support in FullScreen mode (arrow, tab, enter, home, end, pageup/pagedown, space)
2.       Managed APIs for Inking

·          Networking and Data
1.       Cross Domain support in Sockets
2.       Cross Domain security enhancements
3.       BrowserHttpWebRequest and WebClient callable from BackGround Threads
4.       Upload support for WebClient
5.       UI for isolated storage (ability to change quota)
6.       Duplex communications (“push” from Server to Silverlight client)
7.       LINQ-to-JSON
8.       Configuration support for web service proxies
9.       Significantly improved SOAP interop
10.   “Add New Item” template in Visual Studio for “Silverlight-enabled WCF Service”
11.   ADO.NET Data Services support

·          UIAutomation and Accessibility support in platform

·          Media
1.       Platform support for Adaptive streaming
2.       Silverlight DRM, Powered by PlayReady
3.       Basic SSPL support

·          Localization
1.        Changes in application model for multilingual apps (one xap per supported locale)
2.        Expanded localization languages of runtime and SDK

·          Several changes for WPF compatibility

·          Remote Debugging for VB on Mac

·          CLR
1.        Developer Runtime Package facilitate development (localized strings, debugging binaries, etc)
2.        Support the OS fallback logic for resources
3.        CurrentCulture and CurrentUICulture Isolation

·          DLR
1.        Performance improvements
2.        Various new DLR and IronPython 2.0 Beta 2 language features
3.        Various new IronRuby Features

I got a really nice hangover today, not that much drinks yesterday so I think I getting old or am I? ;-)

In this blog post I will share some thoughts regarding the Command-query separation principle by Bertrand Meyer.

This principle main goal is to separate two different behaviors, the Command and Query. The main goal is that a method shall either have a command that perform an action (Changing state) or a Query method that return something (does not change state). A method shall not have both.

Let’s use TSQL for an example to make it clearer. (Remember CQS has nothing to do with only Data Access, it’s common for all objects in your application.)

Command = insert, update, delete
Query = the Select.

Let me show some examples before I go into my own thoughts about it.

private int x;
public int Increment()
{
     x=x+1; <- Command
     return(x); <-Query
}

Here I got a method that performs both a Command and a Query. This isn’t allowed. The correct code should be:

private int x;
public int Value <- Query
{
     get{ return x;}
}
public void Increment() <-Command
{
     x=x+1;
}

The idea about this is based on DbC (Design by Contract), you are well known that only commands change state of the objects and the query methods return the state. CQS is beneficial to DbC because any value-returning method (any query) can be tested by any assertion without fear of modifying program state.

A command cannot return a value but it’s allowed to change state on parameter that passes to it.

In this case this code is ok.

public void Foo(foo someFoo) <-Command
{
      //modify state
      someFoo.Foo = “a value”;
}

But not this:

public string Foo() <-Qurey
{
   //modify state
   return “a value”;
}

I think the idea is nice. I was talking to Patrik Löwendahl regarding this and we were talking about DDD (Domain Driven Design) and the service classes. We talked about if service classes break this principle though you do lots of business related process with them. Take this service code that Patrik gave me as an example.

public Delivery Deliver(Order order)  <- Qeury
{

      Delivery d = CreateDeliveryFrom(order);
      DeliveryR.Save( d );

      order.Status = Delivered; <-- State change on input param

      OrderR.Save(order);

      return d;
}

Is this allowed by CQS?
This is an ok query method because you aren’t changing the state of the object itself even if it’s a query method with commands in it. We never change the object itself state.

What about this code?

public Delivery Deliver(Order order)  <- Query
{
      _delivery = CreateDeliveryFrom(order); <- change object state
      DeliveryR.Save( d );

      order.Status = Delivered;

      OrderR.Save(order);

      return _delivery;
}

public Delivery Delivery <- Query
{
       set { _delivery = value; }
       get { return _delivery; }
}

This isn’t ok. In the above code you break the CQS though you change the state of the object within your query method. The code changes the state of the _delivery class member. If you need this kind of code. Make the query method return nothing and after calling the Deliver method use the property as the query of that delivery class.

I think this is a nice principle. The idea is great as with all principles, the best with principles is that principles aren’t rules they are guidelines that often (in my opinion) helps you get better code.

Nu annordar vi på SweNug Sveriges första och största Code Camp!

SweNug Code Camp är en två dagars träff för utvecklare av alla slag inom .Net. SweNug Code Camp kommer i år att äga rum i Göteborg, 11-12 juni med start kl 10. Eventet är kostnadsfritt och finansieras genom sponsring från ett antal företag. Logi behöver däremot deltagarna bekosta själva!

Organisatorisk kommer vi att ha fyra olika spår som med 60 minuters pass. Vi kommer att hålla på från 10 på morgonen till ca 17 på kvällen. Man kan välja mellan att lyssna eller att själv medverka på de spår man vill. Ordning och fördelning styrs via vår registreringssida www.swenug.com/codecamp

Meningen är att vi utvecklare skall få kunna dela med oss av vår kod och inspireras av andra till egna stordåd. Vill du visa något tufft du gjort och få feedback på det du har skapat? Skynda på att anmäla dig och det som du vill medverka med!

I Frankrike, Spanien, USA och även i vårt grannland Norge är konceptet redan väl etablerat. Vårt mål är att inte vara sämre här i Sverige och sålunda hoppas vi att detta arrangemang ska kännas som ett lite annorlunda event för oss Svenska utvecklare.

 One important thing regarding using Linq to SQL within your architecture is to understand how data has been loaded, when it will call the database for your and how under lying layer loaded your entities.

If you don’t have control over this you can get really bad performance. Especially if you got an aggregate root class with lots of associated aggregates and uses the root as the main object to get the aggregates data.
E.g Let say you got and Order with OrderRows where each OrderRows got an Article. You call for the Order and send it to the UI layer, when this is done you iterate all your OrderRows and print out the Article Names. You got all the Names listed as expected, but what you might not know is that Linq to SQL now called the database for each Article. Let say you got 100 OrderRows then it called the database 100 times one for each Article.

Order order = orderRepository.GerOrderById(34);  //Uses DataContect to load the order here
foreach(Article article in order.OrderRows)
    Console.WriteLine(article.Name);

You can’t prevent this without knowing how or if the data was loaded.
Then only way to check if associated entities was assigned or loaded is by calling the HasLoadedOrAssignedValue property on your associated classes. This will return true if already loaded or false if not.

NOTE! This property only exists if your associations use EntityRef<TEntity>, EntitySet<TEntity> or Link<TEntity> generic types.

So before iterating the OrderRows you check if the OrderRows is loaded.

if(order.OrderRows.HasLoadedOrAssignedValue)
       foreach(Article article in order.OrderRows)
       …
else
     //Do something else

There are two prototypes of the DefaultIfEmpty operator.

public static IEnumerable<T> DefaultIfEmpty<T>(this IEnumerable<T> source);
and
public static IEnumerable<T> DefaultIfEmpty<T>(this IEnumerable<T> source,T defaultValue);

The first one will return the default value of the T. Eg. Let say you have an array of Strings a default value will be null.

Lets say that you got an array with email addresses,  you ask for an address that does not exist without using the DefaultIfEmpty. Eg.

  var name = from x in names

                       where x == "johan@dotway.se"

                       select x;

  Console.WriteLine(name.Single());

An exception will be thrown.
InvalidOperationException with the text:  Sequence contains no elements

This is because the name contains no johan@dotway.se so the Single method has nothing to return.
But if you add the DefaultIfEmpty:
var name = from x in names

                       where x == "johan@dotway.se"

                       select x;

 Console.WriteLine(name.DefaultIfEmpty().Single());

Then it will return null because the Default value of string is null.
With the second prototype you can add the value that shall be returned if nothing exist.
Eg.

var name = from x in names

           where x == "johan"

           select x;

As you might know C# 3.0 deliver features that allow you do create anonymous types.

var x = new { Name = “John Doe” };

It’s recommended that this x type shall only be used within your scope. And as you might know you can’t return a var, but you can return it as an object.
I can’t see the use of returning an anonymous object to other scopes but if you want too there is a simple way to handle this. An old friend Fredrik Klarqvist did a funny solution regarding this. He build his own Cast method to handle anonymous types in different scopes within the same layer.

Only one line of code is needed.
private static T Cast<T>(object o, T type) { return ( T )o; }

       
An exmaple:
static void Main(string[] args)

{

    var myAnonymousObject = new {MyProp = "Johan"};

    var x = Cast(myAnonymousObject, new { MyProp = "" });

    Console.WriteLine(x.MyProp); //returns Johan

}

I’m on a seminar road show regarding Linq right now and often got the question why do I need to use the Attach method?

As you might know we got the Datacontext class that handle all transactions to the databse etc. It also contain to famous Enterprise patterns like UoF (Unit Of Work) and Identity mapping. It’s thanks to the identity mapping technique the Datacontext can handle entities that was obtained from the very same Datacontext instance without using the attach method. This because the Datacontext already know about your entities and there relations etc… If you create a new Datacontext object (as you might do when using a stateless application like a web application) the identity mapping will be lost and not known. Your new Datacontext does not know anything about your entities where it came from, how it’s related against the database, if the entity only needs to be updated or inserted.

The Attach method will help the Datacontext to understand that this entity already exists and shall only be updated and not inserted.

The attached entity adds to the identify mapping so the Datacontext knows it’s already is an existing entity within the relational database.

There are more things you need to know when using the attach method and I mentioned one of them here:  http://www.johannormen.com/blog/viewpost.aspx?PostID=246

Silverlight 2 beta-SDK:n here: http://www.microsoft.com/downloads/details.aspx?FamilyId=4E03409A-77F3-413F-B108-1243C243C4FE&displaylang=en

Blend 2.5-betan here: http://www.microsoft.com/expression/products/download.aspx?key=blend2dot5

And IE8: http://www.microsoft.com/windows/products/winfamily/ie/ie8/readiness/Install.htm

I have worked with Linq to SQL for a while now and done some seminars regarding this topic. Many people ask me what I think about it in a DDDish way. The answer is short. NO I don’t like it. Linq to SQL has lots of lacking support. The biggest lack is for Value Objects. You can’t handle them in Linq to SQL. The Entity Framework will though.

Then you got Lazy Load as default, Ok not a topic for DDD though, but worth mention anyway. The problem with this is the lack of knowledge about your entities in upper layers. You must always ask your entities if the associated entities/aggregates are loaded or not. You can do this by using EntitySet and EntityRef. Your entities will get the HasLoadedOrAssignedValue property.

One nice thing though is the support of the LoadWith dataoption. You can tell your datacontext what associated entities it shall load by default. E.g. the entities you don’t want to Lazy Load later. But there is another problem here that I don’t like. You can’t change the load options on your datacontext after a query has been executed. You must create a new datacontext with new options to handle this. Sad but true.

I think Linq to SQL is more suited for Microsoft own Business Entity architecture with in the P&P. So if you like DDD don’t use Linq to SQL. Wait for entity framework instead or use more mature O/R Mappers like NHibernate.  

When you try to Attach a entity that you changed and want to update it within another DataContext then can get this exception message:
An entity can only be attached as modified without original state if it declares a version member or does not have an update check policy.

This means that your entity can’t be tracked by the new DataContext instance because it don’t know this entity. You might think; but I got an ID. That’s true, the thing is that a DataContext uses an cache with loaded entities and a UoW (Unit of work) for your entity states. When getting an entity from another context the new context doesn’t know your entity because it got no state info about it. The SubmitChange uses the UoW and the cache to verify things regarding your entity. But there is a solution for this the Attach method. You can attach an entity to a new Context so it knows about you. But the change tracking will now work if you don’t tell your new context how the original state looked like or add a version control to it.

Here is an example with a User entity that I use in one of my Linq to Sql demo codes.

User user = GetUserByID(2);

Table<User> userTable = dataContext.GetTable<User>();

user.Name = "new Name";

userTable.Attach(user,GetUserByID(user.ID));

dataContext.SubmitChanges();

I  load a User with ID 2, I change its name and then Attach it to a new DataContext then I Load my orginal state as an parameter for the Attach method.
And then call the new DataContext SubmitChange method.

This will update your user as expected.

To get rid of the double loading of a User entity you can add a version control to it (knows as IsVersion in the metadata). You must add a new property and a new column in the database for your User class and table.

E.g
    private Binary _VersionNumber;

        private Binary VersionNumber

        {

            get { return this._VersionNumber; }

            set

            {

                if ((this._VersionNumber != value))

                { this._VersionNumber = value; }

            }

        }

And Mapping (XML in this example)

     <Column Name="VersionNumber"

          Member="VersionNumber"

          DbType="timestamp"

          IsDbGenerated="true"

          IsVersion="true"/>

Now you don’t need the orginal state.
 

User user = GetUserByID(2);

Table<User> userTable = dataContext.GetTable<User>();

user.Name = "new Name";

userTable.Attach(user);

dataContext.SubmitChanges();

ASP.NET 3.5 Extensions Preview

Brief Description