Code included here is over simplified for clarity, I hosted a better implementation code on CodePlex. These modifications change strictly nothing for the client code and are only an implementation detail. I use a continuation rather than a delay, and I chose to design a custom continuation class rather than using a delegate because of a type system limitations.

Most GUI frameworks, including Silverlight and WPF, are shipped with a fundamental problem: long use of the main thread causes the Window to blackout, and using different threads requires you to get your hands dirty with the Dispatcher stuff and freezable objects. Worse, you wont learn the necessity to do so until you get a surprise of “The calling thread cannot access this object because a different thread owns it.” exception when all what you were doing is to use available methods on an object that seemed you have access to, at lease it seemed until runtime! This post illustrates a solution based on Monads abstraction and LinQ syntax.

This is a problem you get often when applying Model View Presenter pattern [MVP]. There, your view (which is a WPF control) implements a contract IView that the presenter in its turn will use to extract values and then make operations on the view.

interface ISayHello { string GetName(); Unit SayHello(string name); }

class MyLoginControl:Control,ISayHello {

//this interface gets implemented by the corresponding control as texboxes and a text area…

}

The problem appears when for doing any realistic responsive application, the presenter (representing business operations if you’d like) will have to run on a background thread to leave the main thread free for graphics rendering.

While working on a background thread, the presenter needs to access the view (having a reference to it through a contract) and there something wrong happen “The calling thread cannot access this object because a different thread owns it.” . 

The problem here is simply that the view is giving quite a promise that it simply can not satisfy which is implementing the IView contract.

The view cannot satisfy the ISayHello contract under all circumstances, and not even under a commonly desirable condition (the presenter or business code running on another thread). This fact is simply not communicated through the type.

The solution I suggest to this problem that I implemented and employed in a production real world project is based on the LinQ syntax added to C# last year. In the solution I use two things: an extension method and a special type.

The type that I use is the monadic type (thanks to Wesdyer for his enlightening posts): View<T>

So in my case my type will be View<IView> which means that what I am offering here is a a type that acts under some special circumstances as the Contract ISayHello . If I want for example to extract the name from the WPF control, I need to do something with the View<ISayHello>. 

Using the View<T> Monad:

And here comes the LinQ syntax for help. Having a reference to View<ISayHello>, the only way with which I can access the desired value or methods is using Linq:

Having the view contract:

I can extract a view monad that I can pass to the presenter as View<ISayHello> 

note the type View<ISayHello> which is somehow useless without the LinQ syntax:

and you can also use several contracts in the same expression:

Implementation of the View<T> Monad:

View<T> is not really special. It is just a Delay<T> which is a Func<T>. And the Select implementation is the same one for functions and is not special at all:

The fact that I am defining a new delegate type here (View<T>) is because we don’t have type synonyms is C#. And because of this I had to reimplement all the Select methods for this type. Of course all of that Monad plumping code is invisible and all the user needs to do is use the LinQ syntax.

The only specific part about the View monad, is the way you extract it. For Wpf for example the .AsView implementation looks like:

Which merely tells about how to execute the delay when applied.

This is the code responsible for calling on WPF windows using dispatcher and other plumping details. Again code here is simplified for clarity. In the same way one can implement an AsView extension method for Silverlight with no need to change the Select implementation. View<T> is a generic monad and contain nothing specific to GUI technology.

Conclusion

The Monad generalization provides a good solution for WPF/Silverlight thread problem. The solution is barely about communicating through the type system the fact that WPF/Silverlight controls are special, and using LinQ expression to operate on them leaving the plumping (Dispatcher.Invoke, Freezable) to the monad library implementers. Also this frees the caller from thread logic that is specific to the implementation technology.

In my project I didn’t work much on the freezing/unfreezing of Wpf controls (copy them and extract them to other threads) as it actually wasn’t necessary for my project. However, I think that a proper implementation of .AsView for WPF/Silverlight that manages Freezable and nested Freezable objects copying would be very interesting and would complete the API.

PS: I decided to finish this draft quickly as I am not having enough time to finish properly. Please tolerate typos and don’t hesitate to ask questions.

LinQ is often understood in terms of introducing a Domain Specific Language to work with data to C# and .Net in general. The fact is:it is not, and there is a considerable difference between LinQ syntax nature and a DSL. The problem is that DSL definition is blur enough to take anything interesting or cool under it!

Back to the beginning. When faced to doing software for a business that has some moving parts, a good practice is to make a generalization or an abstraction of the fixed part and express what is moving through some sort of configurations. That is in some respect what most of enterprise frameworks do when implementing the fixed part and letting you nicely only express what varies for your context. This way you are almost only concerned about your part since the framework itself is supposed to be steady and well abstracted and as a result implicit in your context. This experience hasn’t been nice enough when XML used to be involved. As someone that defends multi-paradigm design I could argue that XML can play a best fit in some contexts but this is out of the scope of this post. XML charset is not optimal for a lot of cases, so why not creating our own charset, and here comes DSLs.

Of course here I am only talking about the rise of DSLs in the enterprise and not the DSLs that FP been doing for ages, and I’ll get back to this one later.

Now using my favorite meta magical super dynamic language, I’d like to construct my customized embedded(or internal) domain specific language, and I’ll make my best to be English like/business like/ host language unlike to be really specific. And that is where my brains blocks! How can I get grasp of that thing, that ‘lil’ language? It might be a personal problem I have because of the nature of my profession as a consultant: I switch contexts often, and… well I can only hope that it is 1:designed, 2: designed considering practices, rules and well established… did I say patterns?

P for Patterns :

Another way of providing a solution to the problem of generality/variability is use a catalogue of non-formal generalization of recurring solutions to recurrent problems that provide a rich knowledge base of experience about tackling the kind of problem. Being of non-formal nature means that patterns aren’t provided as a framework but rather as a set of vocabulary and description that has its power in being adaptive  and flexible. In my own experience, what I found particularly interesting when working with code that uses patterns is the way they communicate intent. If I find “Strategy” postfix I start searching for the other parts of the patterns and then start building on that. Providing this shared vocabulary helps me getting operational quite fast and help me scan code faster in a more “visual” way.

The good thing also about patterns is that I am still playing under the rules of my preferred hosting language. I know very well doing two very important things with it: combining and abstraction. A programming language is a set primitives together with a way to combine them and a mechanism for abstraction. What about my lil DSL? well it depends… Did I make sure to break any host language logic in there? Did I fight the intuitive nice “.”? Or did I decide that to implement my DSL for scratch? A programming language without means of abstraction results inevitably in long flat copy/paste configurations files and please don’t argue with me about their maintainability. What is the problem? The problem is that I am not a programming language designer, and to create a programming language no matter how simple and small it is, you need to have programming language design skills, so do you?

Abstraction and Communication for People:

Something that really drew my attention in functional programming languages like Haskell is their solid formal abstractions used for expressing computational patterns. These abstractions are packaged into a framework, and have a clear identity defined by a set of rules and are useable whenever semantics match. Take monads for example. It doesn’t matter if you are working with state, a database, the web, the screen or a robitic arm: you just use the do notation. The do notation in Haskell is a convenient way of working with a sound abstraction that is THE MONAD. And all what you need to do for your framework is to verify that you satisfy the Monad laws and then you can safely use that syntax for it. This sharing of well identified semantics of the abstraction help developers reuse a well established mental model. LinQ syntax is the same, the dot “.” operator is the same, F#’s  “|>” operator is the same and examples are a lot. And I tend to prefer these kind of abstractions as they don’t sacrifice readability for developers for “readability” for users. I guess they have both the communicative property of Design Patterns yet they are formal and are offered as a concrete framework. Then of course you can name them DSLs, if you insist :) .

Now, if you are from the functional programming camp, and you have been doing embedded domain specific language using Lisp or Haskell for long time, then I apologize for wasting your time. I know you guys know best about doing abstractions, and you have lessons to tell if we’d only listen. And for those interested in some examples in EDSLs from the functional world, Paul Hudak goes through the design of a language for reactive animation in his book, Lennart Augustsson discussed EDSLs in Haskell on his blog.

Conclusion

Though an attractive option of abstraction, DSLs trade off readability for developers for “potential” readability of users. Haskell monads, F#’s “|>” operator and LinQ are examples of sound formal abstraction that can be offered as frameworks (code). These abstractions can save developers time being in a form of a recurring pattern that can be used in different contexts that match semantically, thus reusing developers’ understanding of the abstraction’s mental model.

http://www.infoq.com/interviews/LINQ-Erik-Meijer

One of the few things that lack seriously, IMO, in C# is the power of Java checked exceptions. In Java world? things happen weirdly. Maybe it is a result of crowd intelligence and a bad side effect of open source. Often, people in J2EE world tend to believe the opposite. Anyway you see the effect in most preferred frameworks (such as today’s popular ORMs and Containers) of wrapping checked Java exceptions and rethrowing them as runtime ones.

I guess offering runtime exceptions together with compile time ones did a hole in the Java type system, but this hole was left to discipline, in a way of giving the tools and letting smart enterprise programmers decide for the right tool for the job. Things turned to happen differently in the enterprise world.  Programmers abused of this freedom of choice and mainstream frameworks designers decided to dismiss and bury one of the most interesting features of the Java type system.

Why do I like Java checked exceptions? Well simply because it saves me from surprises. And I tend not to like surprises much!

The funny thing is that, in my experience, it is mostly architects that dismiss Java checked exceptions whereas Compile time exceptions are a very good asset for cleaner and bug free architecture.

I just take a look at a “standard” DAO method that gets an entity

Customer getCustomer(CustomerId id);

This method lies! what if there is no connection? what if the Id is incorrect? The signature of the methods gives quite a promise that under all circumstances it will returns a Customer. Now for any architecture this is bad. It used to be better before some popular frameworks decided to completely omit it! Before? well I used to control my architecture better!

Before these “good practices” become mainstream, imposed in mainstream frameworks, It used to be often more predictable the return type a method has. For my example, the signature would tell me that the method will either return a customer OR throws a “Dao Exception”.

Customer getCustomer(CustomerId id) throws DaoException;

No surprise. Now when I use this method, I will certainly need to handle the case when the method will return something else than a Customer. Now of course, a Java “enterprise developer” could do one of to things:

1- Out of laziness or incompetence, keep rethrowing data access exceptions up until you’ll have to deal with it up in the GUI logic (where handling an infrastructure error does not often belong)

This often sounds for me the main argument for dismissing Java Compile Time Exceptions claiming that it is a “code boilerplate”. The thing is that you’ll have to deal with these exceptions once even when you turn them into runtime. The fact of wrapping them into runtime does not eliminate them (even if I wish it did). But having them as compile time will make easy to spot where a “bad” developer did not handle the exception correctly simply by following the signature and type system. Then the solution will be to wrap them into more business friendly, context meaningful Compile Time Exceptions that need to be handled. This way the contract communicated better the result of executing a piece of logic.

This turns to be as useful for “void” return type methods. With Compile Time Exception a method can simply communicate the fact that it will either return “void” or will throw an exception to be handled.

2- Out of laziness or incompetence, frustrated developers will start “catch”ing checked exception without rethrowing them.

This one is a result of the hole in the type system that is left intentionally to leave some place for flexibility relying on discipline. Nevertheless, and before the big favor of generous frameworks I mentioned earlier, this turned out to be an easy problem to spot. Most IDEs and code analyses tools can find easily empty catch clauses and warn me about them.

I often get surprised of the limited use of Java language wealth in enterprise J2EE applications!

Good thing: C# and .Net are introducing checked exceptions together with other DbC stuff (like non null objects) in the next release. Sad thing: Java has Compile Time Exceptions since version 1, open source chose to unvalue them!

Having worked with several Object-Relational mapping frameworks in the last few years, I got to a point where I couldn’t justify their complexity in my project. We often talk about the mismatch between the database and the object worlds, and that is where ORMs are often stated and referenced for “bridging the gap”!

Well I prefer to call it lifting the gap, or highering the gap, to have it now between DAOs and the rest of the code than having it between database and code.But I wouldn’t call this in any way reducing the gap.

First thing to mention here, is that data structures are not evil. We often deal with XML data structure but we absolutely refuse to deal with relational data structures. The problem might be related to time, XML came with a whole arsenal of managed APIs that represent its model in a way that makes it more comfortable for you to manipulate these documents. All together with transformation APIs that made it a lot easier to fill your object model out of an XML. Relational data structure on the other hand did not have the luxury of standard APIs and representation models in mainstream languages, and that made dealing with a database request result so arbitrary (Datasets existed in .Net but they have been cursed heavily and has been forced out of the cool toolbox, do not know yet why!) . 

In some way, I guess that the “mismatch” between Relational data structures and objects exists much similarly between XML and objects, however we didn’t think for so long of a doing a mapping between XML and object OXM? (no we are starting to do so, writing some XML to map XML to objects!).

With the experience I had with mapping technologies, I can say that they do not solve the problem for me. They merely add yet another useless level of abstraction where your domain types look nothing like relational data structures, but yet nothing like your target domain model! They have gone a half way, and now its your turn to poison your application with a lot of absurd ORM code trying to stretch this bridge to reduce the gap…

Geeks love talking about intrusivty of an ORMs and compare level of intrusivty in different terms. Intrusivty is much more than the lack of an interface or methods to implement in your domain objects. I guess I am ok to deal with that kind of intrusivity. However all ORMs I tried do not give me the opportunity to express my domain model in the way I would like to. I have to deal with notions of Lazy Loading, Attached/Detached entities, Entity sets, ids, back fields and a lot of other things that I don’t want to appear in my model and that make the resulting code so ugly and complex that I don’t wish to visit soon.

As Bob Martin said before, we are missing the opportunity to do oop, I would enforce and say we are missing the opportunity to model at all. And I guess we have gone too far with ORMs and it is time to go back to the basics, in the same way we have done after the EJB great abstraction.

It is very contradictory, while we are so excited about DSLs and the goodness they can potentially bring to enterprise development that results in a declarative semanticful style of programming, we can’t help but to engage all of our means in trying to bury SQL (and effective, semanticful, declarative powerful domain specific language) behind a dumb API to “abstract database access”! I guess we got to chose one strategy, either we keep SQL and we  keep marketing DSLs or we hope for a new advanced GPL compiler that will hide all of this in the same way modern languages did with garbage collection, concurrency and synchronization.

Since I am not yet a compiler writer, and I aint got around an effective way of integrating database in mainstream languages (there is actually a very productive in memory database on Haskell that worth trying), I decide to keep the DSL, and to work with them without the need to hide them, but rather to get a better tooling to help converting between difference data structures.

I guess you’ve guessed it by now. For me LinQ is the mid-term solution for the data structure mismatch. No not LinQ to sql, nor Ado.Net entities (they are helpful and we might use them but lets focus on the solution). LinQ is a very productive tool that halps effectively transform anything to anything in few lines of code. I mean that I can still use powerful SQL to get data effeciently and then convert them with one line of LinQ into the destination data structure. No abstraction leak, less complexity: Use the right tool where it applies.

So what I would actually do is to use a framework that will execute my SQL or SQL like query on the database and get me the records in much the same way they are in the database,Much in the same way Active Record gets you records as they are in the database. No useless efforts from the framework to bend the data to make it look untruthfully like the destination model.  I guess I know better my domain model, and with this better tooling I can get it done with no problem.

Everyday we hear about languages implementations on the JVM or the CLR. Every language has its own taste and semantics. All of these implementations try the best to satisfy an important second promise which is leveraging the preexisting platform libraries and giving an easy access to them from within that language. So on the CLR you get a promise of an easy access to all the .NET framework, and from Java, well, to the J2EE enormous libraries.

Well designed .Net libraries might be bad designed F# libraries

Some days ago I was trying to solve a small problem using F# (a new member to the .Net family). The reason I chose F# for this problem is the functional paradigm, my specific problem was easier to model using functional paradigm than any other paradigm. What I noticed while using F# is how easy it was to access the large .Net libraries, but I also noticed how can that potentially affect my way of programming. As I already mentioned the reason I chose F# was its semantics, I realized that .Net don’t talk F# and to access it I had to program with its semantics: imperatively, with a command like style almost dropping the expression oriented style that was one of the reasons I chose the language for!

Worse, this drew my attention to how this promise of 100% integrity with the preexisting libraries can affect the language design and implementation. Looking at implementations of popular languages like Ruby and Python on the JVM/CLR one can notice concepts that have almost forced in the languages (like attributes and signatures) . I guess these additions add noise to the language and to the code written with them, but that leads to an important question: How languages should communicate in a multilingual project? And what and where should be the seams when communicating between them?

Some libraries and frameworks are not even necessary for other languages, some just don’t fit, and some need to be wrapped and adapted for the new language

Before trying to think how to communicate between languages, I need to think about what is the kind of libraries I need for the new language. I mean of course it might be technically possible to use Spring and Hibernate when programming JRuby. But in case it is your first choice then, I guess you might be missing the point. There are a lot of frameworks and libraries that have been constructed because of limitations of the language. That is why you need to think twice before just accessing a foreign library because it might be supported natively by your language of choice or its supporting libraries.

Nonetheless , there are some necessary libraries that just don’t exist in your language of choice, and it would be kind of nice to have the painless access to them. But on the other hand, and as stated previously, these libraries don’t talk your language. It is somehow senseless, for instance, to specify type parameters while accessing strongly typed APIs from a dynamic language like Ruby, or say implementing strategies or writing 10 lines of imperative code for configuring a mutable object from a functional programming language like F#.

Some of these necessary APIs can be adapted for the target language. So in this case our issue is solvable by wrapping these well thought mature APIs to make them fit better in the target language paradigm. This can be done using abstractions while leaving other unnecessary details behind like state or type casting. This makes them less intrusive on your paradigm or language. Some libraries’s paradigm, however, is impossible to hide, and in this case you either need an equivalent library for your language, or you need to think carefully about your modules and boundaries to be able to use different libraries with different paradigms without one module being intrusive on another.

Understanding properties and semantics of each used language is the key to a better integration and communication

Each programming language is built and designed based on some theories, principles and concepts. Understanding these does not only help you in your decision of language choice, but this also helps you identifying where and how languages should be communicating. So for example modules written with functional programming languages can be imagined as stateless services that take an input and yield an output, modules written using OOP as holding the state, and modules written with configuration languages place some global, most probably immutable, variables into the environment. This thinking also helps defining barriers between modules to identify when the scope of one language ends for the starting edge of another.

Finally

In this post I tried to draw attention to a hairy, in my view, promise we get from language specification implementers of a seamless integration with existing libraries and frameworks. I guess in the no-fit case, the seam will be in your code and it will obscure it and add noise to your language rather than nicely being abstracted behind a foreign API wrapper. Proper design is instrumental for a non intrusive integration. Properties of each of the used language and frameworks should be considered.

As Aspect Oriented Programming is getting more and more known, a lot of wrong usages appear. Surprisingly, I’ve seen common agreement among J2ee/.net architects for applying it in their application architectures.

First of all, Aspects are not only about the Spring’s  code injection by interception. Even if it looks like interesting, this style of AOP use can be misapplied. One of these misapplications is in transactions. I ve heard it a lot, “All my services are transactions” or “All methods that end with service are transactions” and worse “all of this package (assembly) is transactional!”

Transactions are a part of business logic, they should be explicit in the code, and they should belong to whatever layer they need to belong to. Transactions are not automatic, and cant be applied as an aspect of a whole layer or as an architecture decision.

Yet applying them as Aspects (Aspect) Attributes or Tags is explicit, but they should not be exclusive to somewhere in the architecture, THEY ARE NOT A PART OF THE ARCHITECTURE!

I like the .Net’s implementation of TransactionScope in System.Transactions. It fits rather good to the functional meaning of transactions. I still prefer to have a more explicit code that expresses and treats them. After all, EBay is Transactionless (talking about database technical transactions) and Amazon doesn’t do any Distributed Transactions! That confirms that transactions should be treated as business  notions rather than technical.

I guess it wont be very intresting for readers if I introduce an aspect for loggin all my events and ideas to this weblog! Even if it would be much eaiser for me :) Beleive me, that would be floody!