Walter Almeida's Blog

Season's Greatings - FENOMEN 2010 Achievements

2010 is almost over now. It is time for us to wish all the best to all our friends, family, customers and partners. May 2011 bring your health, happiness, success and harmony in your personal and professional life!

via blog.fenomen.pro

Introducing my favorite ORM Tool: LLBLGEN - Part 2

Ok, time to write again about LLBLGen, my favorite ORM tool. It has been my favorite ORM for years now and I did write a post on the subject several years ago: http://blog.walteralmeida.com/2008/09/introducing-my-favorite-orm-tool-llblgen.html - So this is why I call this post "Introducing my favorite ORM Tool: LLBLGEN - Part 2" :)

For information, I will talk only about the new features that were of higher interest to me. There's much more, so check out Llblgen web site for more info: http://www.llblgen.com

So here we go: Llblgen is now more than never still my favorite tool: since version v3.0; the tools supports several well-known ORM frameworks: Entity Framework, Linq to SQL, NHibernate and of course the Llblgen framework. You now have to a single designer that let you build a data access layer using the ORM framework of your choice. For information, I am still using the Llblgen framework, can’t help it…

And IMHO, the most amazing new feature of all is… the support of model-first development! This was a must have. In the previous version, you had to start from an existing database schema to build your entity model and data access layer on top of it. It is no more the case: you gain in abstraction and can actually start from your entity model! The tool will generate for you the database schema on the target database of your choice, all based on your model. The tool is even capable of generating for you update scripts to integrate your entity model changes to the database: modification, creation and deletion scripts.

Important also to realize that you don’t lose the database first feature: shall you want to build on top of an existing database, or keep full control of your database schema: you still can start from your existing database. And… you can actually mix both and build a part of the data layer in a model first approach and build the rest following a database first approach, which could be a great option if you want to extend an existing database or keep control of mission critical sections of the database schema. You can also start database first and switch later to model first or the other way round. Let’s say: it is very flexible and implemented in a very loose coupled way making all these scenarios possible. I guess this will keep everybody happy and give the option to big believers of one or the other of the approaches to give a try to the other one!

Ok just one word about my view: I am a big believer of the model first approach, in a general way, that is: not only for the data layer, but for full enterprise application. I was therefore very happy when Llblgen V3 came to life!

What else could I say… Oh yes: you now have a graphical designer (called model views) allowing you to build entity models in a very user friendly way. It is also a must have to share with business people on the design of your business model.

What’s more? Full XML project file, which proves very useful to properly integrate Llblgen into your development lifecycle. Indeed, if you follow a model first approach, you then have to consider the model (here the Llblgen project file) as a first class citizen artifact of your project and therefore you should be able to compare versions of your models between several iteration. This is mandatory for proper design reviews. Well no problem to use your standard tooling on top of the Llblgen XML file!

In terms of code and product quality, no need to say that it is top quality, anyone who knows Frans Bouma will understand what I am saying:) No comment: great code, both the generated code and the code base. Nice and neat and effective and bug-free. Well there is no bug-free code, but this code could be considered bug-free when comparing to many other small and big companies. Even the V3 Beta 1 version was already of high quality. And this is essential for a tool that generates code and is targeted at developers. And if you manage to point out a bug: you'll get great first support and have a fix pretty soon available! To be honest: I was much more happy with Llblgen Support than with IBM support... 

Ok now my favorite: extensibility. Llblgen Pro is highly extensible in many ways. And extensions can be written by building on top of the Llblgen SDK. BTW this is actually where you get an even more clear idea of the quality of the underlying Llblgen code. And this is essential for today’s software applications to have this extensibility capability because this is how an eco-system can be built around. In that context, as part of FENOMEN Project (www.fenomen.pro), we have been building for the last two years innovative products that allow the modeling and generation of full enterprise, business applications. And we built on top of Llblgen Pro which is our core ORM framework and entity model designer. This use of Llblgen was essential to quick-start our research and development efforts and build products that really add value to existing market solutions. Indeed why creating what’s already there and took years and years of work to others to master? We are big believers of the “compose and reuse” paradigm: never create what’s already out there: reuse and compose the best of what’s on the market today, and build only what does not exist yet! So stay tuned, you’ll hear about FENOMEN the year to come and will see a great example of the potential of Lllblgen extensibility. And for all whom already now, use and love LLBLGEN, you’ll get a great opportunity to go much further than your best expectations when using LLBLGEN with FENOMEN extensions. Curious? More information in 2011!

 

 

 

 

 

 

SilverLight 4.0 + WCF: How to bubble service error messages to client

Developing with SilverLight 4.0 and WCF for the service side, I wanted to do the following:

1- For known/expected service side exception, I want the user to have a clear feedback with the error message shown to him

2- For all exceptions, and for development scenarios, I want the full exception message displayed back to the user.

I used to do that very easily with rich client (WPF) + WCF service. You indeed just need to add the following behavior, server side, to your service:

 

  
<behavior name="metadataAndDebug">
   <serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>

 

Using SilverLight however, this is not enough. Even with the behavior set, you get the following error message at the client level

the server returned an error :  not found

Not very useful... After some research I found out this is due to a limitation of web browsers and the HTTP stack: By default, WCF services return fault messages with an HTTP 500 response code. Due to limitations in the browser networking stack, the bodies of these messages are inaccessible within Silverlight, and consequently the fault messages cannot be read by the client.

This source from Microsoft explains two workarounds to the issue:

http://msdn.microsoft.com/en-us/library/ee844556(VS.95).aspx

The one I used is the following:

Modify the HTTP status code: You can modify your service to return SOAP faults with an HTTP status code of 200, Silverlight 4 so that faults will be processed successfully. How to do this is outlined below. Note that this will make the service non-compliant with the SOAP protocol, because SOAP requires a response code in the 400 or 500 range for faults. If the service is a WCF service, you can create an endpoint behavior that plugs in a message inspector that changes the status code to 200. Then you can create an endpoint specifically for Silverlight consumption, and apply the behavior there. Your other endpoints will still remain SOAP-compliant. 

This is done by create the following behavior extension:

 

  
public class SilverlightFaultBehavior : BehaviorExtensionElement, IEndpointBehavior
    {         
        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
        {
            SilverlightFaultMessageInspector inspector = new SilverlightFaultMessageInspector();
            endpointDispatcher.DispatchRuntime.MessageInspectors.Add(inspector);
        }
        public class SilverlightFaultMessageInspector : IDispatchMessageInspector
        {     
            public void BeforeSendReply(ref Message reply, object correlationState)
            {
                if (reply.IsFault)
                {
                    HttpResponseMessageProperty property = new HttpResponseMessageProperty();

                    // Here the response code is changed to 200.
                    property.StatusCode = System.Net.HttpStatusCode.OK;

                    reply.Properties[HttpResponseMessageProperty.Name] = property;
                }
            }

            public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
            {
                // Do nothing to the incoming message.
                return null;
            }
        }

        // The following methods are stubs and not relevant. 
        public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
        {
        }

        public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
        {
        }

        public void Validate(ServiceEndpoint endpoint)
        {
        }

        public override System.Type BehaviorType
        {
            get { return typeof(SilverlightFaultBehavior); }
        }

        protected override object CreateBehavior()
        {
            return new SilverlightFaultBehavior();
        }

    }

 

And registering server side this way:

 

  
<system.serviceModel>
    <extensions>
      <behaviorExtensions>
        <add name=”silverlightFaults” 
             type=”Microsoft.Silverlight.Samples.SilverlightFaultBehavior, 
             SilverlightFaultBehavior, 
             Version=1.0.0.0, 
             Culture=neutral, 
             PublicKeyToken=null”/>
      </behaviorExtensions>
    </extensions>
    <behaviors>
        <endpointBehaviors>
          <behavior name=”SilverlightFaultBehavior”>
            <silverlightFaults/>
          </behavior>
        </endpointBehaviors>
    </behaviors>
    <services>
        <service name=”Calculator.Web.Service”>
            <endpoint address=”” 
                      binding=”basicHttpBinding” 
                      contract=”Calculator.Web.Service” 
                      behaviorConfiguration=”SilverlightFaultBehavior” />
        </service>
    </services>
</system.serviceModel> 

 

Warning: There was an issue in SilverLight 3.0 which is still not fixed in SilverLight 4.0:

The Type for the extension has to be specified in one line, with the correct number of white spaces... type definition is checked as string comparison rather that Type comparison... Be aware of that!