Walter Almeida's Blog

I Love .NET Rocks! Or what's great about Podcasts

 

I discovered quite recently the concept of podcasts as a regular consumer, and I must say I am now addicted to it, and I now listen to podcasts all the time: while commuting from and to work, when I go to the gym, when I go running, unfortunately haven't found yet a way to listen while swimming...

I have always been looking to ways to make unused time useful, especially commuting time. I have tried a lot, reading books, looking at videos and webcast on my portative Archos player. And I have found nothing more convenient than audio podcasts! A lot does to it, it is weightless, you can listen in any position, any light condition, and it is so easy to just plug-in your MP3 player when you're back home to get automatic downloads of the new episodes of your favourite podcasts!

I have started my podcast experience by listening to .NET Rocks! Can't even remember the first show I listened but I LOVED it. Since then I have subscribed to other technical podcasts that I regularly listen like Hanselminutes and Software Engineering radio. I have tried once the Polymorphic podcast but was never really convinced. And I must say my favourite remains still .NET Rocks! Great contents, great guests and … real fun! Richard and Carl definitively know how to entertain the audience and make even very technical matters very enjoyable: you can be sure to have several laughs during the listening, which doctors say is very good for your health!

I like Hanselminutes podcasts too, the shows are a bit shorter, making them sometime more convenient to listen if you don't have that much time and don't want to split the listening.

The Software Engineering radio have some good podcasts too. Interesting thing is that this podcast is not specific to any technology, bringing yet another view to some subject (.NET Rocks! and Hanselminutes are specifically shows around Microsoft technologies). However… the shows can be a bit boring in that you will not laugh at all. Gosh, these guys are so serious!! Well anyway some good contents there too, and good content is what is the most important.

By the way, I so like .NET Rocks! shows that I have added a .NET Rocks! tag to my blog to easily link the posts I do sometimes on shows I really liked or want to react on. So check this out here!

So now, after a few months of listening to podcasts, here is my feedback of what I found great in podcasting:

It is definitely a good way to keep informed in an audio format on many aspects of your business or subjects that matter to you: the trends of the markets, technical subjects, business oriented talks, returns on experience etc… It is also a way to hear the voices of big names anyone dedicated to software engineering has probably read articles or books from, and that gives a bigger perspective, other view on the person, and makes you feel as an individual part of a real world made of real people who also can have a laugh while talking about serious, professional matters. Wow, that a long sentence! I guess you get the point: we technical guys indeed tend to read a lot on books or internet, driving us to evolve in a virtual world. And I really fell, the audio, and even more video, gives more life and joy to our business making it more real and lively! You don't feel so lonely anymore and realise that, Hey! There are other freaks out there happening to just love talking for hours about software!!

The other interesting thing about audio/video podcast is that the subjects treated are treated in a very different way than how they would be covered on writen articles. And this is because podcasts are usually interviews and thus are a discussion where a matter is really discussed differently than if one single (or even several) writer would do in a book or magazine: it is more interactive and lively and very open to talks that can easily go beyond the initial subject, thus bringing to the picture yet another perspective, maybe a personal feeling, a real world experience or… just a laugh! You then learn a different way, a more enjoyable way and from a different perspective bringing therefore some added value you would not get another way!

So try by yourself, enjoy the listening, and one or two morning laughs while commuting!

Is the Microsoft Entity Framework more than just an ORM?

I recently listened to the show #369 of .Net Rocks! And read the reaction of Frans Bourma (LLBLGenPro) on the subject.

I wanted to react and give my views on the subject. 

For an overview of what Object Relational Mapping is, please read my previous post on the subject.  

This post assumes that the reader will already have the knowledge of the Microsoft Entity Framework concepts. If it is not the case please read the ADO.NET Entity Framework Overview as a pre-requisite.

Quick introduction to the Microsoft Entity Data Model (EDM)   

The MS Entity Framework is composed of several parts, one of which is the Entity Data Model (EDM). The EDM is used for modelling at a conceptual level the business space, and actually corresponds to the "object space" of the Object/Relational mapping. The EDM is the model describing the set of objects mapped to relational tables on the database side. Then comes the mapping layer, being the bridge or glue between the EDM, or "object side" and the tables in your relational database. Finally, the Object Relational Mapping engine does the trick to manipulate data, persist changes to the database and feed the EDM objects at runtime. An important aspect that will be essential for the main subject of the post is the following: the EDM model is decoupled from the mapping layer and from the ORM engine. In other words the EDM model has no knowledge that there is a mapping and an ORM engine at all, and can be used or re-used without the presence of the mapping and ORM engine. This is an essential pattern for working in a remote/disconnected scenario where a service is responsible for manipulating and persisting data (and thus is using the mapping layer and ORM engine), and the client solely use the data provided by the services, through the form of EDM objects, with no knowledge on how and where the data is stored. Please note that there is nothing conceptually new here and this is the basis of most existing ORM tools of the market, adapted to the Microsoft terminology.

So now that the introduction is made, here comes the main subject of this post.

The Microsoft Entity Framework entering the ORM tools market

For what I've understood from the .Net Rocks podcast, Microsoft could be having more interest on the EDM model than on the ORM engine. You could imagine that this is because they did not manage to catch-up with the existing ORM tools maturity or for a more strategic reason, but that's out of subject here.

Fact is they are many ORM vendors, doing and mastering this job for years and being very mature. The EDM specifically could be on its side more interesting for MS because it is platform oriented and could become a new Microsoft standard, ideal for making applications inter-communicate though this EDM full object oriented, strongly typed object model. Let be clear: the Entity Framework is not a platform, however the Entity Framework and more specifically the EDM model can become an important glue element of the Microsoft platform, becoming the de-facto standard for inter-connecting Microsoft applications and services and any third party application wanting to leverage the EDM opportunity and offer a communication interface to the outer world though EDM entities.

  

A new business opportunity for third party vendors?

What I would extrapolate from Stephen Forte talk in the podcast (and that engages only me) is that there is an opportunity for ORM vendors to build on top of EDM and provide advanced and efficient ORM engine core functionalities: a third party ORM engine replacing the Microsoft one, manipulating and persisting data all through EDM entities. There is also an opportunity for Microsoft Partners to build tools or designers that could assist creating a EDM model and map it to the database + making use of an ORM engine (being the Microsoft one or any other "EDM Compliant" ORM engine). In this scenario, third parties ORM vendors would be using the EDM as the data model used to manipulate, transfer data, between applications and services. Another clarification: the EDM is indeed not a new, revolutionary concept, and every ORM tool in the market is including such a concept: the entities model is indeed the actual object oriented side of the object/relation mapping layer and is an essential part of any ORM tool.

    

Closer look on the EDM on a broader picture

The EDM model becomes a data contract in the WCF sense, making easier and efficient to exchange data between systems, regardless of where the underlying data is stored and whether or not we are using ORM engine to concretely retrieve these EDM entities. For instance you could most probably use and EDM model to represent data in an inter-application communication scenario and not link to any database in the back-end. The EDM and the Entity Framework ORM engine are loose-coupled and you can use one or the other independently. Well at least you can use the EDM independently from the EF ORM engine, I am not too sure of the opposite.

And the EDM is even more than just a data contract: it comes with tools and will probably come with more. One is the Entity SQL, based on SQL syntax oriented toward object queries on the EDM model. And again this is nothing new: for instance Llblgen provides a full framework around its entity model, adding extra functionalities as compared to a basic object model or to any model you could build from scratch by hand, in a reasonable amount of time.

So back to the point: using the EDM as a data contract, it removes the need for applying a DTO pattern for interoperability between systems and especially when exposing services and wanting to make your clients unaware and decoupled from your inner implementation and especially from the ORM tool you are using. Well to be more precise: if the EDM becomes a "Microsoft standard", any one agreeing on that could consume a service delivering EDM entities. But you should be aware that the interoperability will anyway not be complete as using EDM will probably tight you to the Microsoft platform and "Microsoft Entity Framework aware" clients. I will write another post about the DTO pattern in a SOA world and when to use or not use it. DTO is yet another mapping layer and one can wonder why after mapping from the relational world to the object world we still need another translation. My recommendation would be that one should not introduce another mapping layer is there is no absolute need for it. You might need it or might absolutely want to forget about it, depending on the scenario you're in, there is no single solution to all problems.

So is the Entity Data Model much bigger than a just an ORM?

So Yes, for what the EDM is concerned and what you can hear in the podcast as being "more than just ORM", you can achieve the same result with other ORM tool and I am actually doing it on my projects with the LLBLGen Pro generated entities model layer. What however the EDM might provide as a plus in the future is integration in the whole MS suite and become the missing glue link to seamlessly connect systems though the strongly type, object oriented EDM data model. Well let´s be more precise: the missing link in systems based on Microsoft tools and technology.   

So to insist on this point, I can understand Frans Bourma when he is reacting strongly on the sentence "The EF is much more than an ORM" because no, there is no magic and what MS say they can do with the entity framework and the EDM could be achieved with another ORM tool and its own entity model. It is just after all a matter of convention and all actors standardizing on the same framework (and for instance here the EDM part of entity framework). But Yes MS can bring something more with the EDM that goes beyond the ORM aspect, just by the fact that they can push for using the EDM as the data contract layer for all of their products. They can do it because they own the product! And this is what makes the idea powerful: for instance when a company start investing in Microsoft, it usually spread the whole SI and range of applications: start installing MS servers and desktops windows OS and you end up using Exchange server and SharePoint server and office and more and more, rather that competing products. And why? Just because all integrate so well: it is all coming for a single vendor who actually makes the integration of all its range of applications as easy and straight-forward as possible! Same thing can happen with the EDM on a more technical, low level I must say, but following the same driving idea.

      

To conclude …   

To conclude, what I can foresee is that what will bring most to Microsoft strategically speaking is the EDM layer of the Entity Framework. Because this it becomes part of the communication layer, behind the data container for interconnecting the various MS applications. Then how the ORM engine is internally implemented is not of so much importance. And I guess they will be more than happy at Microsoft if a third party ORM engine could be used, and build on top of the EDM and proving very efficient. It will just go in their direction of promoting the entity framework and especially the EDM layer and through the EDM the maturity of their platform and catalogue of products and they will be in a position to market and sell how easy interconnecting them is.

Event based architecture and test driven development

I listened today an interesting podcast related to event based systems and one aspect especially caught my attention: how an event based architecture is a good cadidate for test driven development.

You can find this podcast on DotNetRocks: "Ted Faison takes events to the limit" and the speaker is Ted Faison.

So first interesting point is the difference Ted makes between events based architectures and event driven architectures. Ted describes event driven applications as applications that react to events and therefore whose inputs are events but events are not necessarily used as a core design element of the application. With no events fired, event driven applications are just idle. On the other hand event based applications are applications that are architected and designed with events as a core technique to inter-connect application components. Events in event based architectures are really a first class citizen, design element of the system.

An interesting point is that in a properly designed event based architecture, the inner components of a system are loosely coupled, and you can even imagine changing connexion between components, either statically through configuration, or dynamically at runtime. And high level loss coupling in software architecture is definitely a high goal to aim at.

To design an event based applications, and enforce the components lose coupling and ability to map and inter-connect components in a configurable way, well approved patterns exists to do that, so an event based applications will most probably integrate patterns like builders, binders and coordinators. For instance, to achieve the highest level of loose coupling, neither the receiver of the event nor the emitter of the event should know of each other; and to achieve that, a binder component would have the responsibility to wire and connect the components.

So here we come to the very interesting part of Ted's talk: event based architectures are by essence well suited to test driven applications due to the lose coupling aspect they promote: you can imagine testing single components of your applications without having to bring up the whole application including databases, web context and all expensive or difficult to test resources. And to not bring the whole application up, the only thing you have to do is to simply not connect the components; or to connect to mock up components instead for testing purposes.

And it is commonly understood and approved now that TDD development is a very good practice to build robust, maintainable and flexible systems, even though quite often proving to be a big challenge. Go event based and you have a good starting point! I am personally using dependency injection patterns to build the loose coupled application architectures + dynamic mocking framework for test driven development (more on this on other posts). Event based architecture is another interesting strategy to achieve the same, while having its own advantages and draw-backs. So up to you to decide on one, or maybe any other alternative!

So as a conclusion, I must say that Ted Faison's podcast was very compelling and convincing and an enjoyable listening session, presenting a deep look on amazing possibilities open by using events! It could worth having a look at Ted's book now: Events based programming: Taking events to the limit.