If you have tried any of Erlang, Axum, or even F#, you’ll be familiar with the Actor model and coordinated, concurrent programming using channels. While looking through the Reactive Extensions, released during PDC 2009, I was intrigued by the ISubject<T> and ISubject<T1, T2> interfaces that implement both IObservable<T> and IObserver<T>. I asked whether this could be used as an Actor and received a response from none other than Erik himself that it was possible. Here’s the simple Ping Pong example, similar to those for Erlang, Axum, and F#. The good news is that this same approach will be available in all of the .NET languages, including F#. I wonder what the preferred F# approach will be.

I have read a lot about YAGNI lately, especially regarding TDD. The thing that keeps bugging me is the definition of “simple.” Who defines simple? For instance, wouldn’t static methods be simpler than building objects? You could then write more functionally. Or is that not simpler to you? If you follow command-query separation, wouldn’t building everything as either pure functions or commands be simplest? JB and I have found this set of patterns immensely easy to create and test of late, especially in comparison to the ever-increasing-in-complexity procedural/OO code in place before.

So I guess my question is this: Is it really so bad to start with some basic patterns that will let you refactor more easily? I think the desire to make things as simple as possible–especially when you know you will need it–can be a waste of time and a good way of getting bad code into your source.

I know I will hear it from the Agile community that I just don’t get it, but I think I do. I really like starting simple and keeping things in nice, bite-sized testable chunks. And yes, I’m still learning. However, without a consistent and meaningful definition of “simple,” we’re likely to end up with a follow-up movement of making things complex for the sake of extensibility again.

So what do you think: is CQS too complex a starting point, or is it a nice, “simple,” and testable approach for YAGNI?

This update contains some big changes. You can get this source code here.

The first deployment of the source was very basic.

It didn’t really show anything new or flashy. I did dabble a bit into writing tests in a BDD fashion (or at least attempt to).

I am going to detail out some of the new changes in this source. Naturally there are tests for all the new classes and functionality.

IChangeSet

IChangeSet now only has the GetInserts, GetDeletes, and GetUpdates methods. My thoughts are that the ChangeSet is supposed to only be a readonly entity allowing for investigation into the Unity Of Work. Having the Add methods and Reset exposed too much functionality. A DataContext will just be coupled to its ChangeSet for now. I don’t see any harm in that coupling.

M Model

I created an M file to start building up my domain. I think M is fantastic! I am not a database guru by any stretch so being able to write out a domain in a very readable and manageable syntax is awesome.

module GreekFireExpense
{
    type Expense
    {
        Id : Integer64 = AutoNumber();
        Description : Text;
        Title : Text;
        Amount : Decimal28;
    } where identity Id;
    ExpenseTable : Expense*;
}

I haven’t found a sufficient manner to run the SQL scripts or the M compiler with specific arguments from VS right now. So I am still using IntelliPad to generate the SQL (I am also not a command line guru).

Entity Framework

After creating the database, I created an Entity Framework project. I am created a new DataContext to work with the EntityFramework.

Also the Entities from the Entity Framework do not ‘live’ past the DataContext. The DataContext manages the mapping between my Data Entities and my Domain Entities.

Does anyone know of a project to implement Tutorial D in F#, similar to the Dee project for Python? I’m currently trying to get Dee working on IronPython, which would get me closer to my goal of using a true relational model for data access. I would like to stick with a .NET implementation, so that leaves out Rel. I have tried Dataphor, but I find it trying to be too much a complete platform and not easy to use as just a utility. I think either a good C# or F# implementation would be both excellent to have and a fun project on which to work. Anyone interested?

I’ve been spending some time lately reading and listening to talks on Framework Design and Language Design. In particular, I’ve found Krzysztof Cwalina’s blog and PDC talk very enlightening. I also rather enjoyed the PDC panel discussion on the Future of Programming Languages. I find this all very fascinating, but in a recent desire to apply pragmatism, I wondered how any of this could really help me in my day-to-day development tasks. Except to program to the framework’s design for efficiency and consistency, I had a hard time with that question.

However, with regard to my new hobby of extracting reusable patterns from apps I’m building, I really appreciate the idea of extracting these patterns into small, reusable and interoperable parts. In the Future of Programming panel, Jeremy Siek noted the importance of libraries working with other libraries (e.g., ASP.NET with ASP.NET MVC or ASP.NET AJAX with many Javascript libraries). Some libraries, however, implement their patterns too tightly around certain patterns to the exclusion of others. This can increase speed—Ruby on Rails comes to mind—but removes the ability to use other patterns or pluggable libraries–such as with Merb or Ramaze–to keep to the Ruby frameworks.

JB and I are attempting to extract patterns from our current project to enable faster development in future WPF/Silverlight projects. The current plan is to build our library around Composite WPF, an excellent library from Microsoft’s Patterns and Practices group for building rich client applications in WPF, and soon in Silverlight. We’re planning to build a business layer framework with service interfaces to the Composite WPF library and use the Repository pattern to allow for various data access methodologies.

That’s a loose description of our plan. What do you think? Do you see any flaws? For instance, we are currently not thinking about interchangeable UI libraries, even though a few, such as Silverlight.FX, have started to appear. Are we missing any existing business layer libraries? (I am not familiar with any myself, but I imagine someone has created one somewhere.) We are interested in your thoughts!