JENNIUS Software

Short abstract of HTML 5

2011-10-21T13:56:00.001+02:00

I've recently finished reading Pro HTML5 Programming. The book includes good examples, it is easy to read, and it's a nice introduction to HTML5. Some examples unfortunately didn't work but I guess they were based on an older version of the HTML5 specifications which wasn't supported by my browsers any more.

Following a brief summary of the new HTML5 features ordered by my view of their importance:

HTML5 WebSocket: This is a lightweight duplex communication channel between server and websites and it offers a faster way to send small messages back and forth. A WebSocket can just be opened once the http communication has already been established ("Upgrading the http-connection to WebSocket")
HTML5 Web Workers: A WebWorker is setup by a JavaScript and executes another JavaScript in parallel. Communication to and from WebWorkers is preferably implemented using 'Cross Document Messaging' or messaging via the Web Storage.
HTML5 Web Storage: Stores key/value-pairs in either a session store or a local store. The stores are isolated by their origin (e.g: www.evil.com can't access values from www.example.com). There are events published by the store which are fired when a value changes. Those events can also be used to implement messaging between websites.
HTML5 Canvas: A simple API to render 2D-drawings from within the browser using Java-Script. It's also possible to read and modify parts of the canvas using bitmaps.
Communication APIs: 'Cross Document Messaging' allows sending messages and events between parts of a website even they are not from the same origin. (which hasn't been possible due to security concerns before). 'XMLHttpRequest Level 2' allows the same for communication to the server. It means a website originating from 'example.net' can send XMLHttpRequests to different origins like 'example.net' and 'example.com' at the same time. The import part is that both sender and receiver of 'cross messages' have to be configured accordingly otherwise the communication is not possible due to security constraints.
HTML5 Geolocation: A simple API to access the browser's geographical location. The method of how the location is determined is hidden away by the API. Depending on the kind of browser and hardware the accuracy of the measurement can vary greatly.
HTML5 Audio and Video: Embeds audio and video natively in HTML. Defines controls to play audio and video. Audio and video editing is not included.
HTML5 Forms API: A bunch of new html tags and attributes that provide us with better semantics and therefore enable the browser to render more advanced or different controls. (e.g a control that just accepts E-mail addresses)

I'm really looking forward seeing where HTML5 will take us and what frameworks and paradigms will evolve around it. Will websites become more like traditional rich clients now?

Typing effort analyzer in Ruby

2011-07-30T16:55:00.011+02:00

I've been working on RePhraser over the course of the last 6 months. RePhraser is a piece of software which aims to help professionals in writing repetitive texts quickly. Unfortunately I haven't been able to make it available to a broader audience yet mainly due to the fact that it only works reliably in Internet Explorer and that there are still some basic features missing. Even so, I've uploaded a short demo here.

RePhraser assists you by anticipating and displaying words while you are typing them. Imagine you being a physician who writes the word "immunocytochemically". You would start to type "immu" whereas RePhraser would bring up all the words that start with "immu". There would be simple words like "immune", "immunogen" or more complicated words like the aforementioned "immunocytochemically". In fact there are a lot of words that starts with "immu". RePhraser would be pretty useless if it displayed easy words like "immune" or "immunogen" at this point because professional writers type those words much faster than RePhraser could display them. To solve this problem RePhraser uses a typing effort model. The basic idea is to display words which are harder to type first and to ignore words which are easy to write. To do so RePhraser rates every word based on the carpalx typing effort model. The carpalx typing effort model takes account of things like weak fingers (like pinky and ring finger), travel distance of fingers, same-finger typing (e.g "uhm"), balanced hand-use vs. right-hand priority etc...

I implemented the carpalx typing effort model in ruby and published source code and Gem on https://github.com/Enceradeira/teanalyzer. The project is named Teanalyzer, which is an abbreviation of typing effort analyzer.

What do you think about Teanalyzer? Or are you interested in RePhraser? Please drop a line or contact me!

My days at QCon 2010, London

2010-03-27T20:53:00.005+01:00

This was my first visit at a QCon-conference and I was quite excited to see some of the 'famous' speakers in the world of software development. There were such interesting talks on the schedule that I even missed out on the talks of Eric Evans and Martin Fowler. May be next year!
Generally I jumped between the different tracks but attended more than one talk from the tracks Software Craftsmanship, Functional programming and Irresponsible Architectures and Unusual Architects.

Following talks were my personal highlights (based on the speaker, importance to me, and what I learned from it):

Bad Code, Craftsmanship, Engineering, and Certification by Robert C.Martin. Nothing new, but nethertheless a very entertaining talk. The bad code video was phenomenal (especially with the depressing background music). He questioned if bad code is written because of deadlines, laziness, boredom or even job security ('I´m the only guy that can maintain that!'). He also suggested to follow The Boy Scout Rule: "Always leave the campground cleaner than you found it". "The only way to go fast is to go well" was another of his wisdoms. And then he 'evangelized' agile practices like TDD, pair programming, CI etc... that leads us to what he calls 'Pride of Workmanship'.

Sharpening the Tools by Dan North. Good speaker and motivator. He reflected on the way how we learn things (the Dreyfuss model) and that therefore we are in everything that we learn a 'novice', 'advanced beginner', 'competent', 'proficient' or an 'expert'. He suggested that we have always to renew our skills due to the continuous development of new and more effective techniques in the area of software development:

Practise the basics
Learn from other people
Understand trends
Share knowledge
Maintain your toolbox ('Some tools are timeless, some are disposable')
Learn how to learn

Not Only SQL: Alternative Data Persistence and Neo4J by Emil Eifrém. It was the first time that I attended a talk about this subject and I was very curious about it. I realised soon that it's all about 'scalability'. Like: ´what kind of datastore to you need if you are building a twitter-like-application´. Relational databases are strong with well structured not very complex data (e.g salary-list). NoSQL-datastores are better with more dynamically defined, complex data (e.g: persons and their different relationships to each other). I learned that this is not the end of relational databases but that there are now other techniques available when it comes to storing large amount of complex,dynamic data. I know now that a query like 'all friends of Peter that also know Sarah' can be much more efficient and easier be build with a NoSQL-datastore (especially graph-DB's).

The Joy of Testing by John Hughes. A very refreshing but a little bit academic talk about TDD. The key idea is to abstract test-cases to a set of test-'properties'. Think about a number of test-cases that test a method. Wouldn't it be nice to reduce those test-cases to one unique description that could be run by a test-runner and that this test-runner would find edge-cases that you have never thought about it? I'm not (yet) able to apply this to my daily work but I'm still thinking about it.

Kanban - Crossing the line, pushing the limit or rediscovering the agile vision? by Jesper Boeg. A good talk given by a convinced Kanban-evangelist. It was very interesting how deep they integrate product-owner, buisness-analysts and tester into the development process ('developers helps out business-analyst to write down stories if there is a temporary bottleneck'). Sounds like 'extreme scrumming' to me! (very short full development-cycles). I really like the idea of helping out each other so that we can cope with overloaded/under-staffed testers, productowner and business-analysts.

Command-Query Responsibility Segregation by Udi Dahan. Generally he was saying that displayed data (query-part) could completely be decoupled from the persisted data and on the other hand updating the persisted data (command-part) could be done using a much more sophisticated model (e.g: a strong domain-model or a asynchronous event queue etc...). I already knew about this style but new to me was:

It's about how we build the UI and what business-services we offer to a user. I got the impression we should display less raw-data (e.g: less data-grids) and let the software behave more intelligent.
We could deliberately display stale data (e.g: display a account-list with title 'account-balance as it was on 25.4.2010 at 14:34h'). He says that this is usually no problem to a user.
We could try to build much more valuable commands (e.g: a reservation-system that can ´book the best seats for a group of 12 persons were no person must sit alone' instead of letting the user to choose the seats by itself)

Scenario-Driven Development by Ben Butler-Cole (Unfortunately no slides available). In his talk he was suggesting not to do integration/acceptance-testing on a 'per-story' basis. He mentioned that this could lead to brittle tests and to maintenance problems. He suggested to identify a small number of 'key-scenarios' that spam in their final version several stories. A key-scenario for a banking-application could be: 'Poor guy wants to pay a bill´ that includes the stories 'User pays bill' (that is rejected due to insufficient balance), 'User applies for a overdraft', 'Clerk manages overdraft application', 'User pays bill' (that is not anymore rejected). Scenarios are developed incrementally and extended when a story is going to be implemented. He also showed Twist that was developed by Thoughtworks to support Scenario-Driven Development. An interesting thing is that Twist puts several layer on the top of the application layer, helping to manage reusability and maintainability of the tested UI. These layers are called Scenario-Layer (the scenarios written with Twist, Workflow-Layer (commands like ´go to homepage´) and the Application-model (abstracting the underlying technology with drivers like Selenium). The Workflow-Layer and the Application-model have to be written in Java and enjoy therefore all advantages of a modern programming-language (refactoring,abstraction, object-orientation etc...)

I also attended following less interesting talks:

Functional Approaches To Parallelism and Concurrency
Demystifying monads
Living and working with aging software
The Counterintuitive Web
Patterns for the People
Transactions: Over Used or Just Misunderstood?
Fighting Layout Bugs
Test-Driven Development of Asynchronous Systems
Data Presentation in a Web App: The Journey of a Startup
Death by accidental complexity

Sample Application with White,WPF,TDD and DDD

2009-10-22T16:43:00.025+02:00

I'm currently thinking about what we could do better on a next project avoiding some technical issues that we have had in our latest project. Some of the issues were

The Passive View implementation for our Win-Form client was too costly. The design of it wasn't intuitive and straight forward at all.
The Passive View implementation didn't allow us to unit-test the UI. Even we were able to test the presenters we still couldn't test the event- and data binding automatically .
Our initial plan to do acceptance- and integrationtesting with TestComplete failed. No tests have ever been written with TestComplete.
Our testing-suite runs too slow. The whole suite was too slow and even running one single test took too much time.
We struggled with Aggregates and domain logic leaked sometimes into the presentation layers.
The application is too slow. This was caused due the fact that we couldn't react appropriately when we were forced to move our 2-tier implementation to a 3-tier implementation.

I've recently written a sample application to find answers to some of those problems. You can download the application from this site (Click 'Save file to your PC' at the end of the site).

I'm going to explain my thoughts in detail maybe later, but the most interesting points in the sample application are:

WPF+White: White allows testing the UI right from inside the unit-test runner. Following some basic principals it allows to script the UI right from the c#-code. But I used White just to Unit-Test the UI and to write some basic integration tests. I don't believe that one should use White to do more than that otherwise he might get some serious maintenance issues. For details see OrderExploration.Test\UnitTest\Ui and OrderExploration.Test\Integration
Acceptance-Testing: I think acceptance-testing frameworks are a weak point of the .net-world. Either they require a lot of infrastructure (like wiki's) or they can't be used by "none technical's". NBehave is useless because it can't be used by "none technical's" and it doesn't produce readable code at all (That statement is maybe wrong with Version 0.4, but I didn't check). FitNess is far too complicated for a small project like the sample application. I tried StoryTeller as well, but there is not a lot of documentation available yet, so I gave up. So why not using pure old nunit-tests if there are no "none technical's"? For details see OrderExploration.Test\Acceptance
Persistence-Ignorance: There is just one test that hits the database (see OrderExploration.Test\Integration). All other tests (UI, unit und acceptance) run against stubs.
Test-Setups: To setup Unit- Acceptance- and Integrationtest differently I used SetupFixtures (I didn't know them before!). Lookout for classes with name "SetupFixture"
CQS (Command-Query Seperation) inspired by a Ian Cooper: I tried to separate querying data (mainly for displaying on view) and commanding (mainly for updating on aggregates). I'm not sure if I really got it right! For an example see method DataService.GetOrders() that queries data right from the database and see OrderService.Submit() that writes changes through the aggregate to the database.
Aggregates: See the class Order that defines an Aggregate-Root. I tried to build an expressive aggregate by separating the aggregate from its persisted structure (see class OrderRow) and its displayed structure (see class OrderDetailData). If there is an interest I would like to discuss that decision later. For now see method Order.AddTag() and think about: 1.) If the class Order were directly bound to the UI, how would you handle the fact that the user can add/remove tags several time but just the last state should be persisted and logged in the history. 2.) If the class Order were persisted directly, how would you handle the fact that tags are persisted as strings? (see Order.Tags in the database-scheme)
and StructureMap and AutoMapper ... of course!

Summary

White is cool and helps to (Unit)-test UI
Persistence Ignorance can be implemented and helps to make Unit-/UI-/Acceptance tests much faster
CQS (Command-Query-Separation), ViewModels, DomainModel and PersistenceModel add another layer of indirection that can help to solve tricky problems quite easly. However, these indirections can be a huge overkill for simple applications. I have no doubts that it's worth to have ViewModels (including all kind of MVP,MVC) but I'm not sure when it's worth to separate DomainModel and PersistenceModel. In the sample application, DDD (e.g Repository-Pattern) helped me to answer that question per Aggregate. In the sample application the Aggregate Order has a separated DomainModel and PersistenceModel. For the other Aggregates DomainModel and PersistenceModel are the same. Any thoughts about that?

IObservable ... it's so beautiful

2009-08-03T21:28:00.003+02:00

I've just watched Brian Beckman and Erik Meijer - Inside the .NET Reactive Framework (Rx) and it's again a great work of Erik, Wes and their team.

It's a petty that I couldn't understand all that formalism but i enjoyed it like art and i'm impressed about the beauty and completness of their solution. That's the first mind-blowing feature of .NET 4.0!

Object Role Stereotypes

2009-07-26T20:51:00.005+02:00

I had a short discussions with my college Jürg last week about that classes in object oriented design (especially DDD or RDD) can be classified regarding their responsibility and behaviour. Neither could I remember the name for that concept nor any of those classifications. Jürg mentioned that this is like stereotypes in UML. I looked it up now and he wasn't wrong. They are called 'Object Role Stereotypes'. Not that Object Role Stereotypes are defined by the UML specification but one could use stereotypes in UML to classify classes by their Object Role Stereotype. Here are the stereotypes that I found:

Controller – Controls application execution. Makes decisions and delegates to other classes.
Service Provider – Provides a service to other classes. Performs a calculation, computation, or executes business rules.
Interfacer – Communicates actions to other layers or systems.
Information Holder – Holds facts. Domain classes.
Structurer – Maintains relationships between other classes

How to get the console output working with NBehave 0.4 and the ReSharper Testrunner

2009-03-15T17:04:00.006+01:00

When working with the latest build of NBehave 0.4 you may notice that there is no output written to the ReSharper Testrunner Output anymore.

Here is how I did workaround the problem. I derived the specs from the following class and every thing was fine again:

public class SpecBaseWithConsoleOutput: SpecBase
{
  private EventHandler<EventArgs<MessageEventData>> addedHandler;
  private EventHandler<EventArgs<Scenario>> scenarioCreatedHandler;
  private EventHandler<EventArgs<Story>> storyCreatedHandler;
  public override void MainSetup()
  {
    base.MainSetup();
    addedHandler = (o, a) => Console.WriteLine(a.EventData.Message);
    scenarioCreatedHandler = (o, a) => Console.WriteLine(a.EventData.Title);
    storyCreatedHandler = (o, a) => Console.WriteLine(a.EventData.Title);
    Story.MessageAdded += addedHandler;
    Story.ScenarioCreated += scenarioCreatedHandler;
    Story.StoryCreated += storyCreatedHandler;
  }
  public override void MainTeardown()
  {
    Story.MessageAdded -= addedHandler;
    Story.ScenarioCreated -= scenarioCreatedHandler;
    Story.StoryCreated -= storyCreatedHandler;
    base.MainTeardown();
  }
}

Implementing and testing mapping code with AutoMapper

2009-01-24T11:27:00.009+01:00

I was thinking some months ago that it would be great to have a property mapper that eliminates tedious mapping code . I'm very happy that Jimmy Bogard and his team just have published a framework called AutoMapper that resolves that issue. I haven't tested it yet but the idea looks promising.

Why would I use AutoMapper?

In order to implement better encapsulation and layering with less amount of coding
In order to unit-test mapping code using a simple 'Mapper.AssertConfigurationIsValid()'

TypeMockAutoMocker on CodePlex

2009-01-11T09:54:00.002+01:00

I' ve just uploaded the TypeMockAutoMocker to http://www.codeplex.com/typemockautomocker

How to use it:
1.) Download TypeMockAutoMocker.dll
2.) Copy it to your project and set an assembly reference to it
2.) Set 'Copy local = true' on your TypeMock.dll
3.) Have fun (see Link)

StructureMap 2.5.1 and TypeMock 5.1.2 ist the only tested configuration at the moment.

AutoMocking Container with TypeMock Isolator

2009-01-02T08:20:00.031+01:00

I have implemented an AutoMocking container for the Isolator inspired by an Introduction to the AutoMocking container in StructureMap, the fact that our test setups usually are pretty messy and Jeremy's claim that TypeMock users probably don't care about dependency injection. But why do I want to use DI (Dependency Injection) in conjunctions with TypeMock? I don't want to fight a 'religious war' based on that question, but here is what I think:

TypeMock without DI lacks an explicit boundary that defines what the class under tests is and which classes are mocks or stubs. This is about solid design and to isolate parts of the software in a structured manner. It’s true that you can mock everything with TypeMock but this is just about mocking and not about software design.

DI with another mocking framework than TypeMock is like .NET without System.Reflection. I don't like to use System.Reflection but sometimes it's just the right thing. It’s the same with TypeMock. If everything (own code, legacy-code, external libraries etc.) had a solid design you wouldn't need it but sometime it makes the life so much easier.

Example without Dependency Injection
There is the class under test called ValidationViewPresenter and it has following dependencies:

A a test without DI could look like:

[Test]
public void CanValidateCreditCardNumber()
{
  // Arrange
  var viewMock = Isolate.Fake.Instance<ValidationView>();
  var customerServiceMock = Isolate.Fake.Instance<CustomerService>();
  var creditCardServiceMock = Isolate.Fake.Instance<CreditcardService>();
  var customer56 = new Customer {CreditCardNr = "5500 0001 0001 0001"};

  // Mock the (hidden) dependencies
  Isolate.Swap.NextInstance<ValidationView>().With(viewMock);
  Isolate.Swap.NextInstance<CustomerService>().With(customerServiceMock);
  Isolate.Swap.NextInstance<CreditcardService>().With(creditCardServiceMock);
  // Mock the calls to the dependencies
  Isolate.WhenCalled(()=>viewMock.CustomerNr).WillReturn(56);
  Isolate.WhenCalled(() => customerServiceMock.GetCustomer(56)).WillReturn(customer56);
  Isolate.WhenCalled(()=> creditCardServiceMock.ValidateCreditCard("5500 0001 0001 0001")).WillReturn(true);

  // Act
  var presenter = new ValidationViewPresenter();

  presenter.ValidateCreditCardOfCustomer();
  // Assert
  Isolate.Verify.WasCalledWithExactArguments(() => viewMock.IsValid = true);
}

Example with Dependency Injection
After introducing constructor injection it looks like:

[Test]
public void CanValidateCreditCardNumber()
{
  // Arrange
  var viewMock = Isolate.Fake.Instance<ValidationView>();
  var customerServiceMock = Isolate.Fake.Instance<CustomerService>();
  var creditCardServiceMock = Isolate.Fake.Instance<CreditcardService>();
  var customer56 = new Customer {CreditCardNr = "5500 0001 0001 0001"};
  // Inject dependencies manually
  var presenter = new ValidationViewPresenter(viewMock, customerServiceMock, creditCardServiceMock);

  Isolate.WhenCalled(()=> viewMock.CustomerNr).WillReturn(56);
  Isolate.WhenCalled(() => customerServiceMock.GetCustomer(56)).WillReturn(customer56);
  Isolate.WhenCalled(() => creditCardServiceMock.ValidateCreditCard("5500 0001 0001 0001")).WillReturn(true);

  // Act
  presenter.ValidateCreditCardOfCustomer();

  // Assert
  Isolate.Verify.WasCalledWithExactArguments(() => viewMock.IsValid = true);
}

Example with Automocking Container
Let's eliminate the explicit constructor injection by introducing the TypeMockAutoMocker now:

[Test]
public void CanValidateCreditCardNumber()
{
  // Arrange
  var customer56 = new Customer {CreditCardNr = "5500 0001 0001 0001"};
  var presenterMocker = new TypeMockAutoMocker<ValidationViewPresenter>(MockMode.AAA);

  var viewMock = presenterMocker.Get<IValidationView>();
  var customerServiceMock = presenterMocker.Get<ICustomerService>();
  var creditCardServcieMock = presenterMocker.Get<ICreditCardService>();

  Isolate.WhenCalled(() => viewMock.CustomerNr).WillReturn(56);
  Isolate.WhenCalled(() => customerServiceMock.GetCustomer(56)).WillReturn(customer56);
  Isolate.WhenCalled(() => creditCardServcieMock.ValidateCreditCard("5500 0001 0001 0001")).WillReturn(true);

  // Act
  presenterMocker.ClassUnderTest.ValidateCreditCardOfCustomer();

  // Assert
  Isolate.Verify.WasCalledWithExactArguments(() => viewMock.IsValid = true);
}

As you can see the AutoMocking container couldn’t eliminate a lot of complexity. This is due to the fact that the test itself is complex and there are a number of non-default preconditions.

A better example with AutoMocking Container
Following code tests the same method but with different preconditions again. But this time we can rely on the default behavior that was setup by the AutoMocking container. This means that all involved and not explicitly mocked interfaces or classes do have a default behavior.

[Test]
public void CanHandleNotExistingCustomer()
{
  // Arrange
  var presenterMocker = new TypeMockAutoMocker<ValidationViewPresenter>(MockMode.AAA);

  var viewMock = presenterMocker.Get<IValidationView>();
  Isolate.WhenCalled(() => viewMock.CustomerNr).WillReturn(56);

  // Act
  presenterMocker.ClassUnderTest.ValidateCreditCardOfCustomer();

  // Assert
  Isolate.Verify.WasCalledWithExactArguments(() => viewMock.IsValid = false);
}

Conclusion
There is a big chance that you can get lost using TypeMock and StructureMap in conjunction. The problem is that there are too many ways how they can be combined. However I hope that the TypeMockAutoMocker could help in a way that it's defining a common pattern for how to setup the tests and how to inject the mocks. Remember always:

Depended classes are instantiated by the AutoMocker automatically.
Depended interfaces and abstract classes are instantiated as mocks. These mocks do have a default behaviour where every method can be called.
Depended concrete classes are instantiated by calling its greediest constructor. They are not mocked.
To change the default behaviour you can use Inject() to register your own mock to the AutoMocker. It's how you can setup a mock manually.

Sound’s like ‘convention over configuration’. And that makes life definitely easier.

A Look Back at Our Scrum implementation

2008-12-14T12:29:00.014+01:00

I've been working at my current project for one year now and we are 'nearly done' with our first major release. I know that saying 'nearly done' has a little bit of a bad smell in the agile community but we couldn't do everything perfectly. But generally speaking, we did it pretty well and I'm happy how we could eliminate and master the difficulties of the project with scrum.

We had the following situation at the beginning of the project:

A list of requirements in an excel sheet. The list summarized all the thoughts, requirements and promises in an informal way.
There was a file containing drawings, print-outs from the former legacy system, or other artefacts for each requirement.
The project was embedded in a much larger project, which was driven by Hermes. Hermes is a heavy weight project management process, commonly used by governmental organisations in Switzerland.
Our team consisting out of 6 software developers was hired to implement the software. We proposed to implement scrum and the customer agreed on that.
A contract with a fixed price that was signed a long time before the developers got involved

It was not easy to push scrum from the development into the larger project organisation. There was a good support for our ideas as long there was no organizational change required. Fortunately we could find a pretty good product owner, but we never have had a scrum master. The role of the scrum master was poorly fulfilled by me as a developer.

What worked well?

A lot of things worked great and I'm sure that the project would have failed without an agile approach. Here is what has worked well (see glossary for details on scrum terminology):

User-Stories: After we had transformed the informal requirement list into user stories it was relatively easy to estimate it without knowing the details of each story. Even they were written by us developers it was better than working with the initial list.
Productbacklog: It gave us a very important planning tool, helping us to focus on the near future and driving the development sprint by sprint.
Sprints: The sprints helped us a lot to get the team and the customer focused on the tasks that needs to be done. Without focusing on the sprints and forgetting a little bit about the whole, we could never have done it.
Sprintplanning: Without this meeting we wouldn't have any chance to know what to implement in detail. The customer was surprised at the beginning that he had do discuss every detail of its initial requirement list again in the sprint planning.
Sprintreview: It was often the only opportunity to present our achievements and we always have had valuable feedback from the customer and the future users. Customer and users could get used to our development velocity and that took a lot of pressure away.
Adoption: The product owner discovered during the first two sprints that he needs to be better prepared for the sprint meetings. He started to consolidate the different opinions in additional meetings prior to the sprint planning.
Team forming: Event just two out of six developers have worked together before we never had major problems.

What were the problems?

Scrummaster / Productowner: The roles were never officially assigned to persons, because the customer was confused in relation to the existing roles and responsibilities (project manager, solution architect and so on). There was also no budget available for 'non-programming' tasks.
Importance of the Productbacklog: The Productbacklog was built by the developers and was never owned by the product owner! Once it was initially built up it was used by the management to plan the whole year front up! Development was driven by the Productbacklog, but not testing, acceptance and fulfilment of the contract.
Testing: We couldn’t get things DONE. As the customer didn't test we started to do more functional and system testing. But after one year we do not have any story officially accepted by the customer. But due to the sprint-reviews I'm pretty confident that the customers will accept it after some minor changes.
Sprint-Retrospectives: the meeting was always held by the team but not attended by the product owner, nor attended by another representative of the management. Therefore just team internal impediments could be addressed and resolved. No organizational impediments were resolved.
Meetings: Due to the fact that the whole process was not coached by a scrum master, the meetings usually were ineffective and lasted too long. I, as developer and interim scrum master, was too involved to act as a coach for both the team and the customer.
Responsibility: There were few developers in our team that couldn't follow the process at all. They were not able to catch up the information at the sprint planning nor did they take the responsibility to fulfil the tasks they assigned themselves. We lost a lot of our performance here as senior team members had to coach them. Those weaker developers could not catch up as every thing went far too fast for them.

Conclusion
I'm still saying that agile development is the best practice I know. In my career as a software developer I sat too many times in my office trying to imagine how I could fulfil some requirements that I didn't understand. Today we have a simple process that brings customer and team together and that's much better for everybody. I'm thinking agile development is a process for people that want to take responsibility. If you don't have people that take responsibility you might be better to follow more heavy weight processes were every thing is predetermined and fixed. But everything you can't foresee will cost you a lot of money! It will cost you much more than the salaries of a good scrum master and good developers.

Reflecting about how we implement aggregates

2008-10-16T13:20:00.032+02:00

How we implement aggregates

Since the beginning of my current project we tried to apply the ideas of structuring our business-logic into aggregates. We started to implement the aggregates using the following guidelines:

define an aggregate root and implement it as a public class
define the internal classes of an aggregate and implement it as a public class
implement a repository that can query and return aggregate roots of this class
try to avoid accessing the internals (like traversing from aggregate root to an internal class) from outside the aggregate
put as much as possible of the business-logic into the aggregate root

Following this rules we had some sort of guidelines about where to locate the business-logic and when to implement a repository. I think it was worth to have the aggregates. It was a valuable concept when we had to change our application from a 2-tier to a 3-tier architecture.

Nevertheless we always had following problems with aggregates:

Most of the time we had code in the presentation-layer that accessed the internals of an aggregate. It appeared often in case where there was an one-to-one data binding. For instance, in a master-detail view, where the master was the aggregate root an the detail an internal entity of the aggregate. (e.g. editing invoice and invoice position)
There were relations on the data model that do not comply the aggregate rules. In such a case we often had a nice definition of an aggregate, however there was sometimes a nasty dependency. It happend that an internal entity was depending on another entity in another aggregate. We agreed that this is not bad and that it can be abstracted to a dependency between the two involved aggregates.

And what happened:

Since the internals could be accessed, the business-logic begun to spread out into the presentation layer. It's impossible always to have the discipline to comply the aggregate rules and all of us violated it from time to time.
We didn't centralize the creational-logic. The test code is often a mess and it deals with setting-up the aggregates as well the internals of an aggregate.
A NDepend-analyse revealed that our business-logic assembly will be a serious maintenance problem ('Zone of pain')

Why is our business-logic in the zone of pain?

We generally get closer to the 'zone of pain' (see link for details), when a high number of types in an assembly:

are more concrete than abstract (see Abstractness in the formula)
are used a lot by other assemblies (see Ca in the formula)
do not depend on other types (see Ce in the formula)

Since I can't see any value in implementing business-logic abstract (1.) and our business-logic already depends on a small number of types in other assemblies (2.) the only variable would be to reduce the number of types that are used by other assemblies (3.).

How could we do it different?

We could try to better encapsulate the internals of an aggregate avoiding the problems described above. That means, not allowing to access any internals by another type than the aggregate root. This increases the afferent coupling of the aggregate root, on the other hand eliminates the afferent coupling of the internals. The afferent coupling of the business logic assembly itself would then decrease.

Therefore I transformed one of our aggregates from something like that

// File Invoice.cs
public class Invoice
{
  public EntitySet<InvoicePosition> Positions { get; set; }
}
public class InvoicePosition
{
}

// File Invoice.cs
public partial class Invoice
{
  private EntitySet<Invoice.InvoicePosition> Positions { get; set; }
}
// File InvoicePosition.cs
public partial class Invoice
{
  private class InvoicePosition
  {
  }
}

After completing the refactoring and changing some logic in the presentation layer I got the following code metrics:

The assembly containing the business logic moved a little bit away from the zone of pain (from D=0.577 to 0.575). This is still bad, however the refactoring had a positive effect.
The type-rank for the refactored aggregate root increased from 10.7 to 12. Ca (Afferent coupling) increased from 62 to 66. That means, it got a more important part of the business logic.
The CC (cyclomatic complexity) for the aggregate root increased from 38 to 77, while CC decreased generally for the presentation layer (e.g. in one case from 26 to 16). That means that we put complexity into the business logic. It's a good thing since the complexity generally is easier to test and therefore to maintain in the business logic. It was also possible to eliminate duplicated business logic found in the presentation layer.

Testability and Unittests

As the internals are completely hidden from outside now I test the refactored aggregate with state-based black-box tests. I think that's a reasonable way to do it since the test setup do not depend anymore on the implementation details of an aggregate. I'm not sure if this should be a general testing strategy for aggregates. I think there are more complex cases, where white-box tests would still be needed. The following pictures shows on the left, the test-code before the refactoring and on the right, the test-code after:

TDD, Design and Testability

2008-07-14T21:18:00.007+02:00

After being on holiday for a while and being pretty busy at work I want to talk about an upcoming issue at my current project. The issues are

Presenter-Logic (Passiv View) is hard to test. It costs a lot of effort and it's difficult to be done right.
There is code that is not worth being tested. We shouldn't test that code just to have the test coverage increased.

As a TDD advocate I'm trying to find out what's about those two issues above:

1.Passiv View is hard to test.
Let see an example:

public void EditDienstAbwesenheit()
{
  var abwesenheit = View.SelectedDienstAbwesenheit;  // get selected item from view
  if (abwesenheit != null)  // if user as selected something
  {
    IModalDialog dialog;
    if(abwesenheit is SpitalAufenthalt)  // decide what type of item is selected
    {  // create a modal dialog for this item type
      var presenter = _viewBuilder.Create(_unitOfWork,typeof(ISpitalaufenthaltbearbeitenDialog));
      dialog = presenter.View;
    }
    else
    {  // creat a modal dialog for the other item type
      var presenter = _viewBuilder.Create(_unitOfWork,typeof(IAbwesenheitbearbeitenDialog));
      dialog = presenter.View;
    }
    if (Shell.ShowInModalWorkspace(View, dialog) != DialogResult.OK) // display the modal dialog
    {
        _unitOfWork.Refresh(abwesenheit);  // reload data the might have been modified
    }
    UpdateView();  // show the modification on the view
  }
}

We all know that the more dependencies and responsibilities a method has the more is it hard to test. This is like that because each dependency needs a mock or stub and each responsibility needs a test-assertion to verify it. The example above has following responsibilities:

Get the users selection
Decide about the next dialog to be shown
Create the dialog
Open the dialog in the shell
Reload to rollback modifications of the dialog
Present the changes to the users

To accomplish that tasks we need:

a View to get the users input
a Model (called 'abwesenheit') that represent the users input
a ViewBuilder to create a Dialog
a Shell to display the Dialog
a UnitOfWork to rollback the modifications

So what? Is it a test-problem or a design-problem? I strongly believe that code that can't be tested is poorly designed. The most obvious is that we violate the Single Responsiblity Principle (SRP). Could we split the responsibilities to find methods or even classes to separate the different concerns?

Lets try:

Get the users selection -> Lets keep it where it is
Decide about the next dialog to be shown -> Lets put it into a separate method
Create the dialog -> Lets delegate it to another object as creation and displaying a dialog is often used in an application (e.g Application controller)
Open the dialog in the shell -> move it to the Application controller
Reload to undo modifications -> That's wrong here. The dialogs are responsible not to modify data in case they are cancelled!
Present the changes to the users -> Lets keep it where it is

And after that minor refactoring:

public void EditDienstAbwesenheit()
{
    var abwesenheit = View.SelectedDienstAbwesenheit;
    if (abwesenheit != null)
    {
      CreateEditDialog(abwesenheit);
      UpdateView();
    }
}
public void CreateEditDialog(DienstAbwesenheit abwesenheit)
{
  if(abwesenheit is SpitalAufenthalt)
  {
    _applicationController.ShowInModalWorkSpace(_unitOfWork,typeof(ISpitalAufenthaltBearbeitenDialog));
        }
  else
  {
    _applicationController.ShowInModalWorkSpace(_unitOfWork,typeof(IAbwesenheitBearbeitenDialog));
  }
}

So is that better? I think yes. In terms of Unit-Testing we reduced responsibility and dependency per unit (method) and we got a cleaner more expressive design.

2. There is code that is not worth being tested
Lets see following example:

public class Person
{
  public string FamilyName { get; set; }
  public string Name { get; set; }
  public string Age { get; set; }
}
public class Address
{
  public string Code { get; set; }
  public string Country { get; set; }
  public string Street { get; set; }
}
/// <summary>
/// Model
/// </summary>
public class PersonRow
{
  public PersonRow(Address address, Person person)
  {
    _address = address;
    _person = person;
  }

  private readonly Person _person;
  private readonly Address _address;

  public string FamilyName
  {
    get { return _person.FamilyName; }
  }

  public string Name
  {
    get { return _person.Name; }
  }

  public string Age
  {
    get { return _person.Age; }
  }

  public string Code
  {
    get { return _address.Code; }
  }

  public string Country
  {
    get { return _address.Country; }
  }

  public string Street
  {
    get { return _address.Street; }
  }
}

Is it worth to test that each getter returns the right value? When is it worth to test a piece of code? I could think of following answers:

It's worth if something can go wrong
It's worth if I don't need to put a lot of effort to test it
It's worth if it's likely to be refactored in future

The problem with the example above is that little can go wrong (except the mapping) and that the effort is too high to test it. On the other hand as a TDD advocate I'm a little bit annoyed that this little stupid class should lower our test coverage. So what is the way out?

If this class were not necessary there shouldn't go anything wrong
If we could reduce the lines of code, less could go wrong and less needs to be tested

So let's try to introduce a mapper to externalize the mapping:

public class Person
{
  public string FamilyName { get; set; }
  public string Name { get; set; }
  public string Age { get; set; }
}
public class Address
{
  public string Code { get; set; }
  public string Country { get; set; }
  public string Street { get; set; }
}
/// <summary>
/// Model
/// </summary>
public class PersonRow
{
  public string PersonFamilyName { get; set; }
  public string PersonName { get; set; }
  public string PersonAge { get; set; }
  public string AddressCode { get; set; }
  public string AddressCountry { get; set; }
  public string AssressStreet { get; set; }
}

public void DoTheMapping()
{
  var person = new Person();
  var address = new Address();
  var row = new PersonRow();
  PropertyMapper.To(row).From(person).From(address).Execute();
}

The idea is to eliminate all the boring mappings to a specialized class PropertyMapper. The PropertyMapper would map the values from person and address to the row combining Classname and Propertyname. Furthermore the method Execute() would throw an exception in case any property of the PersonRow was not initialized with a value. My observations are:

The PropertyMapper is difficult to implement, but I think after 10 mappings i have already my return on investment
Execute() is self-validating, therefore this code can also be run under test
I split the responsibilities into two classes (PersonRow and PropertyMapper) and I got testability
The example should be extended to support two way mappings
Is that too much?

Some thoughts about C# 3.0

2008-03-21T17:21:00.007+01:00

We have been using the new C#3.0-features for two months and its quite interesting that our code looks in some parts like Jeremy describes in C#3.0 is like a moped. I wouldn't like to miss the new features and I won't stop using them but I'm thinking it's getting too much.

It makes me feel that C# already had it's best time and there should be something new. Where is the new microsoft-ruby-language? C# was a better Java (I mean the language not the community) but where is now the better ruby?

Behind the scences of LINQ

2008-01-13T08:29:00.000+01:00

I always knew that LINQ was founded on the idea of monads but even trying hard I couldn't understand how LINQ and monads are related to each other.

But fortunately there is Wes Deyer and he describes in The Marvels of Monads what I always wanted to know. It's a pity that LINQ was always described and documented as query language rather than as a monad extensions. When I look to the msdn-documentation there is no hint that I could implement query operators on other types than IEnumerable and IQueryable.

But that's exactly what Wes is doing. He sees a more general concept and he shows a way to implement the query operators on any type. In fact this is for me a huge step and leads us to a new level of abstraction where LINQ (as a list-monad) seems to be a specific case of a monad.

My preferred way to use LINQ was the method syntax as I thought this is the more general case. But now, after knowing that the query syntax is something like a monad extension I start to like it.

Playing around with NBehave

2007-12-29T14:46:00.000+01:00

As I said recently I'm still exploring tdd and its capabilities. The next evolutionary step could be bdd. Therefore I downloaded NBehave and I tried to write one story with it. Passive View is my preferred playground and thats how it goes with NBehave and TypeMock.NET:

First the declaration of the View, the Presenter and a Service-Gateway that is used by the Presenter to retrieve some information.

protected IView _view;
protected Presenter _presenter;
protected EventHandler _updateRequestedEvent;
protected IServiceGateway _serviceGatway;

The setup of the this objects is not showed here. It simples instantiates mocks for the View and the ServiceGateway and injects it into the Presenter using Constructor-Injection. The _updateRequestedEvent is a mocked event on the view and is also used later in the example.

First I have to specify a story. This is done like that:

[TestFixtureSetUp]
public void FixtureSetup()
{
    _getCurrentTimeStory = new Story("Getting the current service time");
    _getCurrentTimeStory.AsA("User").IWant("to update the displayed current time")                
                        .SoThat("I can see what time is on the serivce side");
}

And that's one scenario that came in my mind:

[Test]
public void HelloNTServiceIsNotAvailable()
{
      using (RecordExpectations recorder = RecorderManager.StartRecording())
      {
          _view.ShowMessageBox("The Service is currently not available");
          recorder.CheckArguments();
      }
      _getCurrentTimeStory.WithScenario("Service is not available")
           .Given("the Service returns an exception", new Exception("Error"), e =>
              {
                 using (RecordExpectations recorder = RecorderManager.StartRecording))
                 {
                    recorder.ExpectAndThrow(_serviceGatway.GetTime(), e);
                 }
              })
           .When("I update the current time", () => _updateRequestedEvent(this, EventArgs.Empty))
           .Then("a message box should display", "The Service is currently not available", m =>
              {
                   MockManager.Verify();
              })
        ;
}

Looks quite chaotic and a developer not used to NUnit,TypeMock and NBehave might not understand it at first glance. I also think the combination of NUnit,TypeMock and NBehave is a little bit strange as they do not integrate very well. Maybe there is another way how to combine those frameworks?

But what I like is the overall structure that it gives to the tests and the readable test output that can be interpreted by a product owner. Here are now the scenario above and another scenario that I could present to him:

Story: Getting the current service time

Narrative:
As a User
I want to update the displayed current time
So that I can see what time is on the serivce side

Scenario 1: Service is not available
Given the Service returns an exception: System.Exception: Error
When I update the current time
Then a message box should display: The Service is currently not available

Scenario 2: Service is available
Given the Service returns the time: 01.01.2000 12:24:23
When I update the current time
Then the label on the view should display: 12:24

Evaluating a dependency injection framework

2007-12-16T18:04:00.000+01:00

I heard the first time about tdd in the year 2002 when a colleague of mine introduced me to a tool called 'NUnit'. I found tdd very helpful from the beginning and I was always one of them that pushed that paradigm and mindset. I learned like a lot of the other tdd enthusiasts, that 'test first' is good, that 'test isolation' is really necessary, that a 'mocking framework' helps a lot, and that it's all about a good design. On this journey I'm now at a point where I question: could a 'dependency injection framework' help?

That is what I tried to find out today and what this post is about. I wrote a simple application including:

a wpf client with one window called Window1
a wcf service called Service with one Methode GetDate() that returns the current date and time
one assembly testing the wpf-presentation and wcf-service (just unit-tests)

Introducing a DI-Framework

One trying to write tests in such an environment knows that integrating the real wpf- and wcf-environment into the tests is a bad idea. Instead it's better to stub and mock those environments to get easier, more stable, and faster tests. This means we usually want a test-configuration where the most external dependencies (like wpf or wcf) are mocks or stubs. On the other hand we want to have a configuration on a deployed system that utilizes the real dependencies. So it's something about configuration and that's where the DI-frameworks come into play.

I decided to give Jeremy's StructureMap a try because it doesn't look so overloaded like Sprint.NET or Windsor.

Following code shows my wcf-service IService that I include in the presentation-layer as a Service-Gateway (see also ServiceStub-Pattern):


    [ServiceContract]
    public interface IService
    {
        [OperationContract]
        DateTime GetTime();
    }
    /// <summary>
    /// Gateway to intercept for testing
    /// </summary>
    public interface IServiceGateway : IService
    {
        void Close();
    }
    /// <summary>
    /// Real gateway using the wcf generated ServiceClient class
    /// </summary>
    public class ServiceGateway : IServiceGateway
    {
        private readonly ServiceClient _service;

        public ServiceGateway()
        {
            _service = new ServiceClient();
        }

        public void Close()
        {
            _service.Close();
        }

        public DateTime GetTime()
        {
            return _service.GetTime();
        }
    }
    /// <summary>
    /// Stub for testing
    /// </summary>
    public class ServiceGatewayStub : IServiceGateway
    {
        public void Close()
        {
        }

        public DateTime GetTime()
        {
            return new DateTime(2000, 1, 1, 12, 34, 55, 12);
        }
    }

Step 1:
Using the following code to resolve the reference to the external wcf-service

IServiceGateway gateway = ObjectFactory.GetInstance<IServiceGateway>()

and using the following configuration for the tests

<StructureMap>
  <DefaultInstance PluginType="HelloNTPresentation.IServiceGateway,HelloNTPresentation" PluggedType="HelloNTService.ServiceGatewayStub,HelloNTTests"  Scope="Singleton"/>
</StructureMap>

I could wire the code during the tests to the ServiceGatewayStub instead of the real ServiceGateway.

Step 2:
I didn't like that because it meant that we have to setup a configuration for the real (not test) environment like:

<StructureMap>
  <DefaultInstance PluginType="HelloNTPresentation.IServiceGateway,HelloNTPresentation" PluggedType="HelloNTPresentation.ServiceGateway,HelloNTPresentation"  Scope="Singleton"/>
</StructureMap>

After I have had read how to build an IoC container in 15 lines of code I thought that DI can't be so difficult and I tried to build my own DI-framework. I liked very much that I could configure the DI in the code now and eliminate the file-based configuration:

      ObjectFactory.Register<IServiceGateway>(() => new ServiceGatewayStub());
      IServiceGateway gateway = ObjectFactory.Create<IServiceGateway>();

All tests were green and I was happy to start the refactored sample application first time after. But there was big surprise when it crashed. I had forgotten to configure DI for the wcf-service and wpf-service. But where should I put that configuration? Both of them run in some kind of hosted environment and I wasn't able to find a nice place to put that configuration-code. So I realized that it's a little bit harder than I thought to write an own DI-Framework.

Step 3:
Back to StructureMap I found a way to minimize the file-based configuration. The solution was to use the attributes PluginFamily and Pluggable that define default behaviour. In this case the class ServiceGateway is the default implementation of IServiceGateway and there is no need to configure it for the wcf-service and the wpf-client anymore.

    [ServiceContract]
    public interface IService
    {
        [OperationContract]
        DateTime GetTime();
    }
    [PluginFamily("ServiceGateway")]
    public interface IServiceGateway : IService
    {
    }
    [Pluggable("ServiceGateway")]
    public class ServiceGateway : IServiceGateway
    {
    }

Step 4:
Now let's have a look to following the presenter (presenter is what is responsible for the presentation-logic):

    public class Presenter: IDisposable
    {
        readonly IView _view;
        readonly IServiceGateway _service;

        public Presenter(IView view, IServiceGateway service)
        {
            _view = view;
            _service = service;
        }
    }

That presenter shows all internal dependencies on its constructor. This enables us to use constructor injection when writing tests with a Mock-Framework (e.g. TypeMock)

     _serviceGatway = RecorderManager.CreateMockedObject<IServiceGateway>();
     _view = RecorderManager.CreateMockedObject<IView>();
     _presenter = new Presenter(_view, _serviceGatway);

But what's about the others that don't want to bother about providing those dependencies to the constructor? And that's where the DI-framework gets really valueable because it enables us to instantiate concrete classes without providing the needed arguments to the constructor. Following code is from the wpf-client and shows how this is done:

    Presenter presenter = ObjectFactory.FillDependencies<Presenter>();

Just for completeness, I have to mention how I configured IView:

    [PluginFamily("Window1")]
    public interface IView
    {
    }
    [Pluggable("Window1")]
    public partial class Window1 : Window, IView
    {
    }

Summary

I always used constructor injection but with a DI-framework it gets easier because the client code doesn't need to manage the dependencies anymore.
I like StructureMap because it looks simple and it works.

Offline data synchronization

2007-12-11T21:07:00.000+01:00

I wrote a few days before that it looked like I would get involved in a SOA-project. Today it looks like I will get involved in another project! This new project could have following technical characteristics:

said to be a rich-client-project
support for offline disconnected scenarios (offline agents)
distributed application (Internet, intranet or some kind of private network)
integration with a backend system (no idea what kind of interface that would be)

Sounds interesting .... So I bought yesterday something about WPF to update myself with 'state of the art rich client development'.

Maybe the new Microsoft Synch Framework could be interesting in that context too. I watched this and it looks promising. I have to admit that I hate that kind of presentations but it looks that it's flexible and can be extended. I'm not yet sure about that but at least the synch-runtime can be instantiated in a object-oriented manner and that's always a good sign. Would be great if it could be connected to a service instead of a database.

WCF puts all together

2007-12-09T17:11:00.000+01:00

I was supposed to get involved into a SOA-project therefore I started to read about WCF. In the meanwhile it turned out that I might not be involved in that project, however I kept on doing my reading on this issue. I went through the following two books:

Pro WCF Practical Microsoft SOA Implementation was a good introduction with a lot of code and examples. I liked it as a brief introduction into how WCF 'feels like'. But I switched to the other book soon after since I got more interested in the overall concepts than in the details.

I liked Programming WCF Services because it talks in more details about advanced stuff like Instance Management, Faults, Transactions, Concurrency and Security.

Below is what I think about WCF: I think theres is nothing new but that all comes together in a nice consistent way. WCF helps much if an application is more than a monolithic web or rich-client application. I'd like to mention two personal highlights:

Hosting: An WCF service can be hosted inprocess, as a windows-service, as a console-application or on the IIS.

.NET Integration: Full integration with standard .NET mechanisms like the System.Security, System.Transaction, System.Threading-Namespaces.

excpetion handling could be easy

2007-12-01T17:30:00.000+01:00

We have been doing a major refactoring in our project trying to get rid of the legacy exception handling. As we went through our code we had some good laughs (we shouldn't have laughed as we still have to maintain that for a long time) and it was obvious that some developers had no clue about how to deal with exceptions or were too lazy to implement a more sophisticated handling. It seemed that some developers didn't miss any opportunity to get rid of that nasty exceptions. It seemed that we were fighting a .NET-bug called 'Exception'.

We also had a lot of discussons about exceptions, especially because we wanted to eliminate exception swallowing but not to change the user experience! Our product manager stated that it's better to have an obscure behaviour that the users knows than a new fancy error dialog that indicates problems at the root. (Users don't like fail fast!)

I didn't want to talk about that stuff but I have just come across some similar thoughts:

http://grabbagoft.blogspot.com/2007/11/stop-madness.html (see Try Catch Publish Swallow)
http://grabbagoft.blogspot.com/2007/06/swallowing-exceptions-is-hazardous-to.html
http://grabbagoft.blogspot.com/2007/06/re-throwing-exceptions.html

consistency, integrity and exceptions

2007-11-27T21:41:00.000+01:00

I was blaming myself today talking about consistency and integrity without remembering the exact definitions of it. I just remembered that there are some interesting differences between them. What I meant was a definition like Consistency and Integrity.

My point was that exception handling and especially the concept of design by contract could be seen in a similar context. I tried to argue that violating a design by contract-rule(pre/post/invariance) is like violating the 'programs internal consistency'.

But as Consistency and Integrity is just clearly defined in the context of data it seems that my derivation doesn't make sense.

In personally would say a 'program consistency' is maintained as long it's internal state doesn't contain any contradictions. Furthermore a 'program integrity' is maintained as long as the programs internal state does reproduce all related external state correctly.

Following that definition one could say that 'program consistency' can be checked by the design by contract-technique but 'program integrity' cannot. 'program integrity' cannot be checked at all by a program.

Expresso - Regextool and others

2007-11-20T19:30:00.000+01:00

I used Expresso first time today and I liked it much more than the Regulator that I've used up to now . The 'Regex Analyzer'-View and the 'Search Result'-View display the Regex and the matches as a tree and this helps me a lot in understanding Regex's.

I've always wanted to mention that I'm using a visual studion plugin named Cool Commands. I'm using just one command of it: 'Collapse All Projects' . It collapses my 20 projects in a solution with one click! Will the brand-new visual studio 2008 support that out of the box?

Scrum and xp from the trenches

2007-11-11T16:47:00.000+01:00

I've just finished reading Scrum and xp from the trenches. To see that everybody trying to adapt Scrum is running into the same kind of problems perks me up. Scrum like its written in the books is quite dogmatic but this book gives some good pragmatic advices.

Two remarks about what I've read related to the project I'm currently working on:

We are trying to adapt a simple estimation method where we compare the complexity of use-cases choosing a number from 1,2,3,5,8,13 ... One use-cases is randomly chosen as a 'reference use-case' and all other use-cases are estimated by comparing it with the 'reference use-case'. Estimating use-cases is a reoccurring activity in our project and the problem is that every team member has always to remember a 'reference use-case' in its details to be able to give an estimate to another use-case. Using that method we had a kind of 'currency' to determine the real value in time (how many hours is one point?). Calculating 'Total Points in a Sprint' * 'currency' gives us the total amount of working hour of the team in a Sprint.
Maybe we should switch over to a system where 1 Point is '1 ideal programming day'. We could still use an exponentially growing number like 0.25, 0,5, 1,2,3,5,8,13... to address the growing uncertainty. The drawback is that we might have to deal now with number less than 1 but on the other hand it gives us a better feeling on how much work is related to one certain number. Furthermore our 'currency' gets a 'focus factor' and that's easier to understand by managers and addresses directly the question why we cannot deliver as fast as in an 'ideal environment'. I guess comparing use-cases according to their complexity is a good choice for a single 'planning-meeting'. However in our case where we estimate a small number of use-cases monthly, it's better to pin the points to '1 ideal programming day'.

Patterns 4 - Domain Driven Design

2007-10-28T15:45:00.000+01:00

Im vorläufig letzten Beitrag zu Patterns möchte ich einige Patterns aus dem Buch Domain Driven Design von Evans auflisten. Leider sind die Patterns nicht Online verfügbar, doch gehört dieses Buch sowieso zur Pflichtlektüre wenn mit Domain Model's gearbeitet wird. Wer es weniger theorietisch mag und sehe möchte wie sich das Arbeiten mit DDD 'anfühlt' dem sei Applying Domain-Driven-Design and Pattern von Nilson empfohlen.

Supple Design
Unter dieser Überschrift sind Patterns enthalten welche die Absicht und Wirkung von Code möglichst transparent darstellen lassen sollen. Idee ist dass die Struktur des Code die Funktionalität möglich klar darstellt.

Side-Effect-Free-Functions: Mit diesem Pattern können, auch in Kombination mit unveränderbaren 'Value Objects', einfach verständliche und testbare Funktionen realisiert werden. Für das Verständnis und das Testen müssen nur Inputparameter und der Resultatwert der Methode berücksichtigt werden da keine Seiteneffekte vorhanden sind. Weiter wird empfohlen Commands (Methoden welche beobachtbaren Zustand verändern) in sehr einfache Operationen zu gliedern welche keine Domäneninformationen retournieren.
Assertions: Im Code sollen Pre-/Postcondition und Invarianzen definiert werden. Damit sollen auch Seiteneffekte explizit spezifiziert werden damit für das Verständnis einer Methode nicht alle Ausführungspfade analysiert werden müssen.
Intention-Revealing Interfaces: Hier gehts es darum dass Klassen- und Methodenamen gefunden werden welche die Funktionalität und Verantwortlichkeit klar ausdrücken. Es sollte nicht nötigt sein dass daneben noch dokumentiert werden muss, unter welchen Umständen eine Klasse und Methode wie funktioniert. Auch sollten im Namen Begriffe aus der 'Ubiquitous Language' auftauchen.
Standalone Classes: Gelingt es eine völlig losgelöste Klasse, ohne Abhängigkeiten auf andere Klassen zu entwickeln, reduziert man die konzeptionelle Komplexität massgeblich. Lose Kopplung kann eingesetzt werden um die Komplexität von Code zu reduzieren.
Closure of Operations: Dieses Konzept hält uns an Operationen wie mathematische Operationen aufzubauen da diese ein einfaches Konzept ist. Dabei sollen Eingabeparameter und Rückgabwert vom gleichen Typ sein. Ein solches Interface ermöglicht das Zusammenbauen von komplexeren Operationen aus einfacheren Primitiven.
Specification: Ein Value Object welches als Predicate bestimmt ob ein anderes Objekt ein bestimmtes Kriterium erfüllt.
Ubiquitous Language: Dabei sollen Begriff und Konzepte aus der Problemdomäne von den Entwicklern übernommen werden. Diese Begriff und Konzepte haben ein starken Einfluss auf den Design und sind einer der wichtigsten Treiber für den Design.

Building Blocks
Hier haben wir Patterns welche unter DDD häufig vorkommen.

Layered Architecture: Schlägt vor im allg. eine Applikation in Presentation, Application, Domain und Infrastruktur Layer zu schichten. Dies ermöglicht einen ausdrucksstarken Domainlayer zu erhalten da dieser nicht mit Anzeige-, Speicher-oder Berechtigungsaufgaben usw. überladen wird.
Entities und Value Objects: Wichtige Konzepte zum Unterscheiden von Klassen mit Identitäten (z.B: eine Person mit einer ID) und Klassen deren Identität durch die Werte der Klasse bestimmt ist (z.B eine Farbe identifizierbar durch ihre RGB-Werten). Es wird empfohlen Value Objects als unveränderbare Klassen zu designen.
Modules: Gibt Anleitunng nach welchen Aspekten Code modularisiert werden sollten. Dabei sollte auf geringe Kopplung und hohe Kohäsion geachtet werden. Modulnamen sollten Teil der Ubiquitous Language werden. "If your model is telling a story, the Modules are chapters".
Services: Im allg. sollte für jeden Service gelten: 1.) Die Operation auf dem Service ist Teil des Domänenkonzept welches aber nicht als Entitiy oder Value Object ausgedrückt werden kann. 2.) Die Service-Schnittstelle nimmt Bezug auf das Domänenmodell. 3.) Die Operation ist zustandslos. Desweitern kann ein Service in verschiedenen Schichten realisiert werden (Application-, Domain-, Infrastructure-Service) wobei sich die Verantwortlichkeiten je nach Schicht stark unterscheiden können.
Factories: Erzeugt in einer Operation ein konsistentes Objekt oder Aggregate (Invarianzen müssen erfüllt sein). Dieses Pattern wird wichtig sobald ein Objekt nicht mehr mit einem einfachen Konstruktoraufruf erzeugt und in einen konsistenen Zustand überführt werden kann.
Repositories: Lädt Objekte oder Aggregates von einem tieferen Infrastrukturlayer in den Speicher (z.B von der Datenbank) und erzeugt die Illusion dass die Objekte immer im Speicher vorhanden sind. Repositories werden spezifisch für Klassen von Objekten und Aggregates realisiert und zeigen auf ihren Schnittstellen die Designentscheidung bezüglich Objektzugriff.
Aggregates: Damit werden eine Anzahl von Entities oder Value Objects logisch gruppiert um die Kopplung zwischen Teilen des Modells zu reduzieren. Pro Aggregate wird eine Klasse als Aggregate-Root definiert und der Zugriff auf das Aggregate darf nur noch über diesen Root erfolgen.

Strategic Design
Hier sind Patterns aufgelistet welche helfen in einem grösseren, komplexen System das Domänenmodell und verschiedene Teile davon herauszubilden.

Core Domain: Definiert die wichtigste Domain in einem Projekt. Für diese wird mit grosser Sorgfalt das Modell gefunden und ständig verfeinert. Jegliche Art von Entscheidungen können nun so gefällt werden dass es zuerst der Core Domain zu Gute kommt.
Generic Subdomain: Eine Subdomain ist nicht der Hauptgrund weshalb eine Software entwickelt wird, doch ist die Subdomain (z.B ein Zeitzonen-Modell) eine wichtige Unterstützung der Core Domain. Solche Domänen sollten aus der Core Domain gelöst werden um diese nicht unnötig komplex zu machen. Auch können Generic Subdomain häufiger als Core Domains wiederverwendet oder auch eingekauft werden. Vor und Nachteile beim Einkaufen von Sumdomänen sind in diesem Kapitel auch erläutert.
Domain Vision Statement: Schlägt vor dass die Coredomäne und ihr Wert zu Projektbeginn beschrieben wird um dem Entwicklungsteam eine gemeinsame Richtung zu geben.
Segregated Core: Beschreibt den Vorgang wie aus einem System ohne Core Domain eine solche gebildet werden kann.

Large-Scale Structure ist ein Kapitel in welche einige Patterns enthalten sind welche helfen ein Struktur für grosse Systeme zu finden.

Maintaining Model Integrity beschreibt Ansätze wie Modelle zwischen unterschiedlichen Systemen synchron gehalten werden oder wie mit den Unterschieden umgegangen werden kann.

Patterns 3 - Enterprise Application Architecture

2007-10-18T09:24:00.000+02:00

Wie der Titel dem geneigten Leser andeutet möchte ich in diesem Beitrag das Standardwerk Patterns of Enterprise Application Architecture, kurz EAP, von Martin Fowler zitieren. Im Gegensatz zu den GoF-Patterns aus meinem ersten Beitrag zu Patterns sind die EAP-Patterns recht spezifisch mit einer Anwendung verbunden. Im folgenden werde ich eine Auswahl von Patterns aus dem Buch auflisten indem ich die Zusammenfassung aus dem Buch pro Pattern zitieren und wo es für mein Verständis wichtig war habe ich noch Kommentare hinzugefügt. Für Details sei an das Buch verwiesen. Nicht erwähnte Patterns sind nicht weniger wichtig, doch haben sie in meinem Umfeld weniger Bedeutung da die Problemstellung nicht vorhanden ist oder ich diese bis heute durch ein Framework lösen lies.

Domain Logic Patterns
Domain Model: 'An object model of the domain that incorporates both behavior and data.' Wegen Domain Driven Design ist dieses Pattern für mich ein Muss.

Service Layer: 'Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation.' Für den Service Layer gibt es die Variation 'Domain Facade' und 'Operation Script'. Da ich den Domain Model-Ansatz bevorzuge habe ich hier auch eine Bevorzugung für die 'Domain Facade'. Die Eigenschaften eines einzelnen Service hat Evans auch hier beschrieben.

Data Source Architectural Patterns
Active Record: 'An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.' Dieses Pattern kann zu einer Vereinfachung in der Implementation eines Domain Model führen indem die Datenbankstruktur und die Domain Model-Stuktur gleich gehalten werden.

Data Mapper: 'A layer of Mappers that moves data between objects and a database while keeping them independent of each other and the mapper itself.' Im Gegensatz zum Active Record wird das Mapping hier in den Data Mapper ausgelagert. Der Data Mapper wird in der Regel nicht selbst implementiert da dies ein komplexes Unterfangen ist (z.B kann für ein objekte-relationales Mapping NHibernate verwendet werden). Auch wird ein Data Mapper oft zusammen mit einem Domain Model verwendet. (siehe auch Mapper)

OR Behavioral Patterns
Unit of Work: 'Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.' Unit of Work sollte in der Regel zusammen mit einem Data Mapper implementiert werden.

Identity Map: 'Ensures that each object gets loaded only once by keeping every loaded object in a map. Looks up objects using the map when referring to them. ' Identity Map muss im Zusammenhang mit einem Data Mapper implementiert werden.

Lazy Load: 'An object that doesn't contain all of the data you need but knows how to get it.' Wichtiges Pattern in Zusammenhang mit Data Mapper und Domain Model um zu steuern wann welche Daten von einer Datenquelle geladen werden.

OR Metadata Mapping Patterns
Query Object: 'An object that represents a database query.' Das Specification Pattern ist mit Query Object verwandt. Der Unterschied ist dass das Query Object auf technischer Ebene ein Query beschreibt. Das Specification Pattern selbst kann Begriffe aus der ubiquitous Language verwenden und bilden und ist Teil der Geschäftslogik.

Repository: 'Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects'. Ich war hier immer unsicher was der Unterschied zwischen einem Repository und einer Factory ist. Aber in Domain Driven Design von Evans wird klar definiert: 'The Factory makes new objects; the Repository finds old objects' und in Applying Domain-Driven Design and Patterns wird dargestellt dass das Repository für die Persistierung von neu erzeugten Objekten zuständig ist. Ein Repository befindet sich auf einer höheren Ebene als ein Data Mapper indem es Query Object oder Specifications auswertet und Objekte mit Hilfe eines Data Mapper erzeugt.

Web Presentation Patterns
Model View Controller: 'Splits user interface interaction into three distinct roles. (View, Controller, Model).' Siehe auch MVP unter welche das Pattern weiter verfeinert dargstellt wird.
Page Controller: 'An object that handles a request for a specific page or action on a Web site'. Ich sehe im Page Controller eine Anpassung des Model View Controller an das Web-Umfeld wo es die View einmal auf dem Client als HTML-Seite und einmal auf dem Server als Server-Seite gibt. Dies ist auf jeden Fall der Grund weshalb im Unterschied zum Model View Controller die View keine Abhängigkeit auf den Page Controller hat. Die clientseitige HTML-Seite hat nämlich eine Abhängigkeit auf den Page-Controller indem diese Web-Requests übermittelt.

Front Controller: 'A controller that handles all requests for a Web site'. Der Controller instanziert abhängig vom Request Commandos welche die weiteren Verarbeitungen vornehmen.

Template View: 'Renders information into HTML by embedding markers in an HTML page.' Das ist wie eine ASP-Serverseite.

Application Controller: 'A centralized point for handling screen navigation and the flow of an application'.

Distribution Patterns
Remote Facade: 'Provides a coarse-grained facade on fine-grained objects to improve efficiency over a network.' Wichtig ist, als Unterschied zum Service Layer, dass die Remote Facade grob-strukturierte Methoden aufweist.

Data Transfer Object: 'An object that carries data between processes in order to reduce the number of method calls.' Kann zusammen mit Remote Facade zur Datenübertragung verwendet werden. In .NET werden so oft DataSet's oder XML-Serialisierte Objekte als DTO über Webservices verwendet.

Offline Concurrency Patterns
Optimisitc Offline Lock: 'Prevents conflicts between concurrent business transactions by detecting a conflict and rolling back the transaction.'

Pessimistic Offline Lock: 'Prevents conflicts between concurrent business transactions by allowing only one business transaction at a time to access data.'

Coarse-Grained Lock: 'Locks a set of related objects with a single lock'. Damit verwaltet ein Optimisitc Offline Lock oder ein Pessimistic Offline Lock die Locks auf höherer Ebene (z.B: Aggregate) um den Lockingaufwand zu verringern und die Konsistenzsicherheit zu erhöhen.

Implicit Lock: 'Allows framework or layer supertype code to acquire offline locks.' Stellt sicher dass das Locking implizit ist und somit vom Client-Code weder vergessen noch umgangen werden kann.

Session State Patterns
Client Session State: 'Stores session state on the client.' Wird z.B von ASP.NET-Seiten als ViewState implementiert. Kann aber auch für alle Arten von Sessions verwendet werden.

Server Session State: 'Keeps the session state on a server system in a serialized form'. Wird z.B von ASP.NET-Seiten auf dem System.Web.HttpContext.Session -Property implementiert.

Database Session State: 'Stores session data as committed data in the database.' Kann bei ASP.NET via Konfiguration für den Server Session State eingeschaltet werden.

Base Patterns
Gateway: 'An object that encapsulates access to an external system or resource.' Vereinfacht ein komplexes externes Inteface und stellt evtl. die Basis zur Verfügung um einen Service Stub anlegen zu können. Noch ein paar Erklärungen: Ein Gateway wird für externe Komponenten geschrieben während eine Facade von einer externen Komponente zur Verfügung gestellt wird. Ein Adapter wiederum ist eine technische Möglichkeit wie ein Gateway umgesetzt werden kann.
Mapper: 'An object that sets up a communication between two independent objects.' Ist komplexer zu implementieren als ein Gateway. Der Mapper kann als Zwischenschicht gesehen werden welche die zwei angrenzenden Schichten aufeinander abbildet. Beide angrenzenden Schichten bleiben dabei unabhängig und nur der Mapper hat eine Abhängigkeit auf diese.

Layer Supertype: 'A type that acts as the supertype for all types in its layer.' Mag ich persönlich nicht da dadurch schnell das Single Responsibility Prinzip verletzt wird. (z.B Domain Model hat Subertype für Persistenz).

Separated Interface: 'Defines an interface in a separate package from its implementation.' Die Konfiguration der konkreten Instanz (welche das Interface implementiert) kann danach von einem dritten, von beiden Packages abhängigen Komponente oder per Plugin zur Laufzeit erfolgen.

Registry: 'A well-known object that other objects can use to find common objects and services.'

Plugin: 'Links classes during configuration rather than compilation.' Dafür gibts heute eine Anzahl Frameworks (z.B Spring.NET). Plugin wird häufig auch im Zusammenhang mit dem Dependency Inversion Principle und Separated Interface verwendet.

Service Stub: 'Removes dependence upon problematic services during testing.'

Record Set: 'An in-memory representation of tabular data.' = DataSet in .NET

Patterns 2 - Prinzipen

2007-10-14T11:48:00.001+02:00

Im zweiten Beitrag zu Patterns möchte ich einige Prinzpien ansprechen welche helfen einen ausgereiften und qualtitativ guten Softwaredesign zu finden. Diesen Prinzipien zu folgen ist nicht immer ganz einfach, aber sie machen schlussendlich den Unterschied zwischen einer längerfristig wartbaren und qualtitativ hochstehenden Software und einem Hack aus.

DRY: Das Prinzip 'Don't repeat yourself' besagt dass in der Programmierung keine Duplikationen und Redundanzen enthalten sein sollen. Dies gilt für den Programmcode, für Datenbankdefinitionen usw... Das befolgen dieses Prinzips erhöht die Wiederverwendung von Programmcode enorm und ist Ausdruck einer sauberen Programmierung schlechthin.

Law of Demeter: Vereinfacht gesagt definiert das Gesetz von Demeter die Regel 'Sprich nur mit deinen engsten Freunden'. Damit wird erreicht dass eine Klasse sich nur an das nächste Umfeld koppelt (die engsten Freunde) und nichts über die Struktur des weiteren Umfelds wissen muss. Das Gesetz definiert formal für die Methode M auf dem Objekt o:

o.M() -> darf auf Methoden von o zugreifen (z.B mit this.X())
o.M(a) -> darf auf Methoden von a zugreifen (z.B mit a.X())
0.M() -> darf auf Methoden von selbst erzeugten Objekten zugreifen (z.B a = new A() wird in der Methode M() angelegt, dann darf o.M() -> a.X() aufrufen)
o.M() -> darf auf Methoden von direkt aggregierten Objekten zugreifen(z.B a = new A() wird im Konstruktor angelegt, dann darf o.M() -> a.X() aufrufen)

Open/Close Principle: Das Prinzip verlangt dass eine Softwarekomponente (Module, Klasse, Methode usw...) erweitert werden kann ohne dass die Komponente in ihrer inneren Struktur angepasst werden muss. Der Sinn dahinter ist dass eine Komponente ihre Verantwortlichkeit (gemäß Single Responsibilty Principle sollte da nur eine sein) erfüllt ohne sich um die entsprechenden Variationen kümmern zu müssen. Für die Variation sollte die Komponente aber entsprechende Erweiterungpunkte mittels Delegation an Abstrakte Interfaces oder Vererbung durch Abstrakte Methoden gegen aussen zur Verfügung stellen. Auf der anderen Seite sollte die Komponente auch ihre interne Struktur gegen aussen verbergen. Dies ermöglicht dass die Komponente ihre Implementation ändern kann, ohne dass Erweiterung und Variationen davon betroffen wären.

Single Responsibilty Principle: Das Prinzip besagt, dass ein Komponente (Module, Klasse, Methode usw..) genau eine Verantwortlichkeit haben soll. Eine Komponente sei somit nur anzupassen, wenn bezüglich dieser Verantwortlichkeit die Anforderungen ändern. Um dies erreichen zu können müssen folgende wechselwirkenden Aspekte betrachtet werden.

Es sollte eine hohe Kohäsion erreicht werden. Eine Komponente hat ein hohe Kohäsion falls sie eine wohldefinierte Aufgabe abschliessend und vollständig löst (siehe auch Link)

Durch lose Kopplung sollen Komponenten über ein wohldefinierte und möglichst kleine Schnittstelle miteinander verbunden werden

Mit Separation of Concerns sollen die Verantwortlichkeiten in einer Software systematisch aufgeteilt werden. Dabei werden die Verantwortlichkeiten eindeutig an ein Module, Klasse oder Methode übergeben.

Liskov Substitution Principle: "Methoden welche Basisklassen (auch Abstrakte Klassen oder Interfaces) als Parameter haben müssen diese Objekte benutzen können ohne die konkrete Klasse zu kennen". Dies bedeutet für die Überschreibung einer Methode oder die Implementierung einer Methode aus einem Interface:

Vorbedingung dürfen nicht verschärft werden
Nachbedingungen dürfen nicht abgeschwächt werden
Es dürfen nur Klassen von Exceptions geworfen werden welche auch von der Basis-Methode geworfen werden oder als mögliche Exception dort dokumentiert wurde. Es dürfen auch Ableitungen von diesen Exceptions geworfen werden

Eine Verletzung des Liskov Subsitution Principle führt zu einer schlecht funktionierenden Umsetzung des Open/Close Principle da sich die Erweiterung instabil verhalten wird.

Dependency Inversion Principle: Das Prinzip hat zum Ziel einen flexiblen und somit wartbaren Design zu finden. Die Regeln besagen:

Übergeordnete Komponenten (Module, Klasse, Methode usw...) und untergeordnete Komponenten sollten nicht direkt voneinander abhängig sein. Beide sollten nur von Abstraktionen abhängig sein.
Abstraktionen sollten nicht von den Details abhängig sein. Details sollten von den Abstraktionen abhängig sein.

Das Prinzip ist auch für den TDD Entwicklungsansatz enorm wichtig, da dadurch das mocken und stubben von untergeordneten Modulen ermöglicht wird. So gesehen stellt TDD einen flexible Design sicher, da der übergeordnete Code im Unitest mit Mocks und Stubs und in der laufenden Applikation mit den konkreten untergeordneten Modulen arbeitet.

Noch was vergessen?

Patterns 1 - Gang of Four

2007-09-24T19:46:00.000+02:00

Seit ich mich mit Entwurfsmuster, oder eben Patterns wie ich normalerweise sage, beschäftige haben sich einzelne Steine zu einem grösseren Mosaik zusammengefunden. Das Mosaik hat noch viele Lücken, aber ich möche hier alle mir wichtig erscheinenden und von mir verstandenen Patterns zusammenfassen. Dies ist mein aktuelles "Weltbild" des objektorientierten Software-Designs. Noch ein Wort zu meiner Welt. Meine Welt ist die der grösseren datenzentrierten Geschäftsanwendungen, mit einer Rich-Client Benutzeroberfläche.

In der Folge möchte ich in mehreren Beiträge diese Patterns auflisten und zusammenstellen. In einem ersten Beitrag gehts es um die 'Gang of Four - Patterns' welche eine Ansammlung von systemnahen, technisch orientierten Patterns darstellen.

Abstract Factory: Erzeugt eine Familie von Objekte unterschiedlicher Typen ohne dass man bei der Benutzung gegen eine konkrete Familie programmiert. Als Beispiel dient hier eine IDbFactory welche IConnection, ITransaction für den Datenbankzugriff erstellt. IDbFactory kann nun konkrete für SQL-Server oder Oracle implementiert werden ohne dass es für den Benutzer von IDbFactory einen Unterschied ausmacht.

Builder: Abstrahiert den Konstruktionsprozess für komplexe Objekte. Falls erforderlich kann der Konstruktionsprozess für andere Typen wiederverwendet werden. So kann zum Beispiel das abstrakte Erstellen einer Rechnung mit einer Anzahl Rechnungspositionen mit einem abstrakten Builder realisiert werden. Als Varianten für konkrete Builder wäre ein KreditorenrechnungsBuilder und ein DebitorenrechnungsBuilder möglich

Factory Method: Erzeugt ein Objekt wobei die implementierende Subclass über den konkreten Typ des erzeugten Objekts entscheidet. Ist mit dem Abstract Factory-Pattern dadurch verwandt, dass dort eine Familie von Objekten und hier nur ein Objekt erzeugt wird.

Singleton: Stellt sicher, dass eine Klasse nur einmal instanziert ist und global zugegriffen werden kann. Damit kann zum Beispiel eine Infastrukturdienst wie die Protokollierung einfach für alle Programmstellen zugreiffbar gemacht werden. Das Pattern sollte aber sehr bedacht eingesetzt werden, da man sich damit sehr einfache versteckte Abhängigkeiten baut, welche die Flexibiltät und Wartbarkeit von Programmcode stark einschränken.

Adapter: Ermöglicht den Zugriff auf eine Klasse via ein Interface welches die Klasse selbst aber nicht unterstützt. Als Beispiel könnte man damit in einer Windows.Forms-Anwendung Controls über eine Interface IControl ansprechen obwohl die Windows.Forms-Library kein solches Interface unterstützt. Ein ControlAdapter würde dann Control auf IControl adaptieren.

Composite: Ist eine Datenstruktur in Form eines Baumes mit Vater-Kind-Beziehungen. Jeder Knoten im Baum ist wieder ein Composite mit weiteren enthaltenen Composites oder dann ein Leaf (Blatt) ohne weiteren Composites.

Decorater: Damit kann zur Laufzeit ein Objekt dynamisch erweitert werden. Bestehende Methoden können erweitert werden und auf dem Decorater können neue Funktionalitäten für das Objekt realisiert werden. Als Beispiel könnte man damit eine Klasse Strassenverbindung abhängig von der Strassensituation als GesperrteStrasse oder als StrasseMitStau instanzieren was dann das Verhalten der Strassenverbindung zur Laufzeit beeinflusst.

Chain of responsibilty: Ermöglicht dass eine Anforderung oder eine Meldung von einer Anzahl Objekten verarbeitet werden kann, wobei jedes Objekt eine spezifische Aufgabe wahrnimmt und die Meldung an ein nächstes weiterleitet. Als Beispiel kann das Verarbeiten einer Meldung in verschiedenen Schritten angesehen werden: 'Dekomprimieren der Meldung' -> 'Authentizität der Meldung prüfen' -> 'Meldung interpretieren' usw....

Command: Bildet eine Anfrage an ein Objekt ab und erlaubt damit Transport, Protokollierung, Persistierung usw. der Anfrage. Zum Beispiel kann damit ein Command in einer Queue gespeichert und zu einem späteren Zeitpunkt ausgeführt werden.

State: Ermöglicht einem Objekt sein Verhalten abhängig von einem Zustand zu ändern. Die Implementation des Verhalten wird an den State delegiert.

Strategy: Kapselt einen Algorithmus in einer Klasse und ermöglicht damit eine allgemeine Verarbeitung mit spezifischen Strategien zu parametriesieren. So könnte damit die Berechnung einer Strassenverbindung mit der 'KuerzesterWegStrategie' oder mit der 'SchnellsterWegStrategie' parametrisiert werden. Der darunterliegende Berechnungsalgorithmus ist somit unabhängig und kann mit verschiedenen Strategien kombiniert werden.

Template Method: Kapselt Teile eines Algorithmus in Methoden und erlaubt Subklassen diese Teile zu implementieren. Somit realisiert eine Basisklasse das Grundgerüst eines Algorithmus und die Subklassen können einzelne Verarbeitungsschritte verfeinern.

IO und funktionale Programmierung in C#

2007-09-09T13:32:00.000+02:00

Zusammenfassung
Das seiteneffektfreie Programmieren ist in der funktionalen Programmierung ein wichtiger Grundsatz, welcher in der imperativen Programmierung (z.B C#) oft vernachlässigt wird obwohl dadurch höhere Nachvollziehbarkeit, Wiederverwendbarkeit und Testbarkeit erreicht werden kann. Im folgenden wird Anhand eines Beispiels gezeigt wie eine Konsolenausgabe seiteneffektfrei realisiert werden kann.

Einleitung
In der funktionalen Programmierung werden Seiteneffekte und Zustände wie der Teufel das Weihwasser gescheut. Leicht passiert es dass durch Seiteneffekte Methoden und Klassen, bei entsprechend ungeeignetem Design, ein nicht deterministisches Verhalten zeigen, was Zuverlässigkeit, Stabilität und Fehleranalyse von Programmen umgemein behindert. IO-Operationen können als Beispiel für Funktionalitäten dienen welche gezwungenermassen Seiteneffekte aufweisen.

string line = System.Console.ReadLine();

Wartet das Programm im Methodenaufruf ReadLine() auf eine Benutzereingabe, so ist nicht sicher ob der Aufruf jemals einen Wert zurückliefert (z.B falls der Benutzer am Bildschirm eingeschlafen ist und somit keine Eingabe macht). Weiter liefert der Aufruf ReadLine() bei jedem Aufruf unter Umständen einen anderen Wert zurück, obwohl aus Sicht des Programmes nichts geändert hat. Dieses Verhalten ist in der imperativen Programmierung (C#) normal, in der funktionalen Programmierung aber verpönnt da in dem darunterliegenden mathematischen Verständnis der Programmierung kein Platz für Nichtdeterminismus und Zufall ist. Auch die Methode System.Console.WriteLine() macht aus mathematischer Sicht wenig Sinn da sie keinen Rückgabewert hat und den Zustand des Programmes nicht verändert.

Beispiel
Wie könnte man nun die Seiteneffekte für folgendes Beispiel beheben?

static void Main(string[] args)
{
    int index = 0;
    var numbers = new int[] { 1, 3, 7, 10 };
    foreach (var number in numbers)
    {
        System.Console.WriteLine("Index {0}: {1}", index++, number);
    }
    System.Console.ReadLine();
}

Lösung

Die Seiteneffekte können zwar nicht ganz eliminiert werden da eine Ausgabe auf die Console nun mal erwünscht ist. Die Idee ist es den Seiteneffekt an eine unkritische Stelle zu verschieben und den Zustand der gewünschten Ausgabe explizit abzubilden (wie dies ein Monad in der funktionalen Programmierung macht).

static void Main(string[] args)
{
    System.Console.Write(
        new int[]{1,3,7,10}
            .Select( (number,index)=> string.Format("Index {0}: {1}{2}", index,number,Environment.NewLine))
                .Aggregate( (lines,line) => lines + line));
    System.Console.ReadLine();
}

Unter Verwendung von LINQ wird mit Select und string.Format() jedes Listenelement in eine Ausgabenzeile projiziert. Danach werden alle Zeilen mit Aggregate und 'lines + line' in einen einzigen String aggregiert welcher am Schluss auf die Konsole ausgegeben werden kann.

Da unsere Funktion nun die Ausgabe explizit abbildet, können wir Tests schreiben und prüfen ob die Ausgabe korrekt ist:

[TestMethod]
public void TestOutput()
{
    string output = new int[]{1,3,7,10}
                    .Select( (number,index)=> string.Format("Index {0}: {1}{2}", index,number,Environment.NewLine))
                        .Aggregate( (lines,line) => lines + line);
    Assert.AreEqual( "Index 0: 1" + Environment.NewLine +
                     "Index 1: 3" + Environment.NewLine +
                     "Index 2: 7" + Environment.NewLine +
                     "Index 3: 10" + Environment.NewLine , output);
}

C# 3.0 vs. Haskell und das 'Countdown-Problem'

2007-08-26T11:21:00.000+02:00

In 'Programming in Haskell' wird eine Lösung für das Countdown-Problem in Haskell vorgestellt. Im folgenden wurde diese Lösung in C# 3.0 übersetzt und der Unterschied zwischen Haskell und C# 3.0 analysiert.

Das Countdown Problem
Das Countdown Problem lautet wie folgt: Gegeben seien eine Folge positiver ganzer Zahlen, die Quellzahlen, und eine positive ganze Zahl, die Zielzahl. Gesucht wird ein arithmetischer Ausdruck, in dem jede der Quellzahlen höchstens einmal auftritt und der als Ergebnis die Zielzahl liefert. Als Operatoren können in dem Ausdruck +, -, * und / verwendet werden, wobei jedes Zwischenergebnis ebenfalls eine positive ganze Zahl sein muss. Zum Beispiel löst für die Quellzahlen [1; 3; 7; 10; 25; 50] und die Zielzahl 765 der Ausdruck (1 + 50) * (25 - 10) das Problem. [Referenz: http://www.mathematik.uni-marburg.de/~loogen/Lehre/ws06/Konzepte/Uebungen/u6.pdf]

Unter diesem Link kann die Lösung in C# heruntergeladen werden.
Die C#-Lösung unterscheidet sich zu der Haskell-Lösung vorallem dadurch, dass in C# objektorientierte Konstrukte eingeführt wurden. Nachfolgend eine Auflistung der Haskell-Features welche nur erschwert in C# abgebildet werden konnten

Rekursive Typen wurden als Klassenhierarchien abgebildet. Folgender Haskell-Code
```
data Expr = Val Int  App Op Expr Expr
```
wurde in C# zu
```
public interface IExpression{}
public struct Value : IExpression
{
    public Value(int value){}
}
public abstract class Operation : IExpression
{
    protected Operation(IExpression l, IExpression r){}
}
public class Add : Operation
{
    public Add(IExpression l, IExpression r) : base(l, r) { }
}
public class Sub : Operation
{
    public Sub(IExpression l, IExpression r) : base(l, r) { }
}
public class Mul : Operation
{
    public Mul(IExpression l, IExpression r) : base(l, r) { }
}
public class Div : Operation
{
    public Div(IExpression l, IExpression r) : base(l, r) { }
}
```
Während der Haskellausdruck an Produktionsregeln erinneren und somit eine internal DSL bilden, fehlt in C# 3.0 eine solche Möglichkeit. In C# wurde der dieser Ausdruck als ein Expression-Tree abgebildet. Die Anwendung des rekursiven Typs sieht in Haskell wie folgt aus:
```
evaluate( App Add( Val 2 ) ( Val 3 ))
```
während in C# der Expression-Tree wie folgt instanziert und evaluiert würde:
```
new Add(new Value(2), new Value(3)).Eval();
```
Das Problem an der objektorientierten Lösung in C# ist, dass in der Anwendung immer Objekte erzeugt werden müssen. Dies verlangt das Schlüsselwort 'new' welches im Gegensatz zum Haskell-Beispiel, den Ausdruck verschleiert. Auch ein FluentInterface bringt in diesem Fall nichts, da damit keine Ausdrücke verschachtelt werden könnten.

Lazy-Evaluation wird für die Lösung des Countdown-Problem benötigt, ansonsten alle Lösungskandidaten am Anfang der Berechnung in den Speicher geladen werden müssten. Lazy-Evaluation ermöglicht die Berechnungsfunktionen so zu kaskadieren, dass nur immer die gerade benötigten Resultat ermittelt werden und dass nicht mehr benötigte Zwischenresultat sofort im Speicher freigegeben werden können.
Während in Haskell diesbezüglich keine Vorkehrungen nötig sind muss in C# explizit jede Berechnung und Berechnungsschlaufe über IEnumerable erfolgen. Verwendet man LINQ und Extension-Methods so können alle Haskell-Lösungen in die entsprechende LINQ-Lösung übersetzt werden. Aus der Haskell-Funktion
```
solutions :: [Int] -> Int -> [Expr]
solutions ns n = [e  ns' <- choises ns,
                      e <- exprs ns',
                      evaluate e == [n]]
```
wird in C# 3.0 zu
```
public static IEnumerable<IExpression> GetSolutions(IEnumerable<int> values, int result)
{
    return values.Choises().SelectMany(choise => choise.Exprs()).Where( exp => exp.IsValid() && exp.Eval() == result);
}
```

Pattern-Matching ist ein Konstrukt um die Komplexität pro Funktion oder Methode zu reduzieren. Die Haskell-Funktion

perms :: [a] -> [[a]]
perms []     = [[]]
perms (x:xs) = concat (map (interleave x)(perms xs))

behandelt den Fall der leeren Liste und den Fall der nicht leeren Liste in zwei getrennten Funktionsimplementionen. Da C# Pattern-Matching nicht kennt müssen dort die beiden Fälle in der Methodenimplementation durch eine if-Anweisung explizit behandelt werden:

public static IEnumerable<IEnumerable<int>> Perms(this IEnumerable<int> list)
{
    if (list.Count() == 0)
    {
        return new int[][] { new int[] { } };
    }
    else
    {
        return list.Skip(1).Perms().SelectMany(subList => subList.Interleave(list.First()));
    }
}

Listen sind in Haskell tief in die Sprache eingebettet. Folgendes Beispiel
```
perms :: [a] -> [[a]]
perms []     = [[]]
perms (x:xs) = concat (map (interleave x)(perms xs))
```
ist im starken Kontrast mit C# 3.0:
```
public static IEnumerable<IEnumerable<int>> Perms(this IEnumerable<int> list)
{
     if (list.Count() == 0)
     {
         return new int[][] { new int[] { } };
     }
     else
     {
         return list.Skip(1).Perms().SelectMany(subList => subList.Interleave(list.First()));
     }
}
```
Folgendes kann beobachtet werden:
- x in Haskell entspricht list.First() in C#
- xs in Haskell entspricht list.Skip(1) in C#

Listen haben unter C# einen langen Leidensweg hinter sich:
- .NET 1.0 kennt untypisierten Listen aus System.Collections
- .NET 2.0 unterstützte typisierte Listen aus System.Collections.Generic
- ab Visual Studio 2008 wird nun LINQ eingeführt

LINQ ist grossartig doch leider kommt es sehr spät. Eine grosse Erneuerung ist die Erkenntnis dass man anstellen von Listen nun mit IEnumerable's arbeitet. Während Listen (z.B List) in .NET die Eigenschaft der Eager Evaluation haben, wird mit IEnumerable Lazy-Evaluation erreicht (siehe auch oben). Leider muss man sich in Zukunft immer explizit für 'Eager' oder 'Lazy'-Evaluation entscheiden und es wird immer einen konzeptionellen Bruch zwischen den beiden Ansätzen geben. Die Verwendung von IEnumerable (Lazy-Evaluation) ist auf jeden Fall der Verwendung von IList,ICollection usw. (Eager-Evaluation) vorzuziehen.

Zusammenfassung
Mit C# 3.0 lassen sich einige Konzepte aus der funktionalen Programmierung anwenden. Diese Konzepte sind allerdings in einer funktionalen Sprache wie Haskell eleganter umgesetzt. Dagegen steht im Kontrast dass in Haksell objektorientierte Konzepte fehlen, welche vorallem für den Bau von grossen und komplexen Softwaresystemen benötigt werden (z.B Abstrakte Datentypen)

Domain-Driven Design von Eric Evans. Kapitel 1-2

2007-08-17T17:51:00.001+02:00

Nachfolgend fasse ich die Kapitel 1-2 vom Buch Domain-Driven Design von Eric Evans aus meiner Sicht zusammen. Folende Patterns zeigten für mich neue Aspekte auf und werden meine Arbeit in Zukunft beeinflussen.

Layered Architecture: In diesem Kapitel werden die verschiedenen Schichten wie 'Infrastructure Layer', 'Domain Layer', 'Application Layer' und 'Presentation Layer' konkret im Zusammenhang mit Domain-Driven Design beschrieben. In Kombination mit dem Pattern Model-View-Presenter habe ich nun eine Idee, wie ein Model darin aufgebaut werden könnte.

Modules: Das Kapitel zeigt mir auf, dass bei der Auftrennung von Modules (Namespaces,Assemblies) eher Grenzen zu wählen sind welche in der Fachdomäne auch vorhanden sind. So macht es zum Beispiel eher Sinn anhand von Begriffen wie 'Kundenverwaltung' oder 'Rechnungmodul' Module aufzuteilen, als anhand von Begriffen wie 'DomainLogic', 'DataServices' usw. Die führt dazu dass die Module eine geringe Kopplung aufweisen und eine abgeschlossene Einheit bilden.

Aggregates: Das Pattern hilft durch seine Regeln das Domänenmodell auf einfache Art und Weise übersichtlich und somit auch wartbar und einfach verständlich zu halten. Hätte ich früher noch über Module nachgedacht um die Kopplung zwischen Teilen des Domänenmodels zu reduzieren, geht das nun mit Aggregates deutlich einfacher und flexibler. Mir hatte immer eine Element im Design gefehlt wo spezielle Verantwortlichkeiten wie z.B Validierung und Konsistenzprüfung untergebracht werden konnten. Dies kann nun einfach im Domänenmodell selbst im Aggregateroot untergebracht werden. Allerdings habe ich auch schon gesehen, dass im Aggregateroot Infrastrukturdienste wie die Persistierung untergebracht wurden. Hier muss man sich aber strikte an die Verantwortlichkeiten des Domänenmodells und somit eines Aggregates erinnern und nur Domänenlogik implementieren.

Factories und Repositories: In beiden Kapitel wird konkret erläutert was die Verantwortlichkeiten von Factories und Repositories sind. Während Factories für das Erstellen von neuen Objekte und neuen Aggregates zuständig sind, behandeln Repositories das Auffinden und Instanzieren von persistierten Objekten und Aggregates. Mir werden diese Kapitel in Zukunft helfen, unabhängig von dem unterliegenden Datenzugriffsmechanismus einen einheitlichen, objektorientierten Design für die Persistenzschicht zu finden.

Programming in Haskell (durch die C#-Brille gesehen)

2007-07-29T12:59:00.000+02:00

Während des letzten Monats habe ich das Buch 'Programming in Haskell' durchgearbeitet. Es hat mir einen guten Einblick in die Welt der funktionalen Programmierung ermöglicht. Obwohl ich mir nicht die Zeit nahm jedes Beispiel und jede Übung bis ins letzte Detail zu verstehen, habe ich doch einige Konzepte verstanden welche meine Arbeit als Softwareentwickler in Zukunft beeinflussen werden. Folgende Punkte waren für mich neu und haben mich beeindruckt:

Abstraktion auf Ebene von einzelnen Funktionen und Operationen
Folgender C#-Code berechnet die laufende Summe über einen Array von Integers:

 public static int[] GetLaufendeSumme(int[] values)
 {
    int[] summierung = new int[values.Count()];
    int sum = 0;
    for( int i=0; i<values.Count(); i++ )
    {
       sum = values[i] + sum;
       summierung[i] = sum;
    }
    return summierung;
 }

In Haskell habe ich nun mit Hilfe der Funktion foldl folgende Lösung gefunden:

getLaufendeSumme :: [Int]->[Int]
getLaufendeSumme = foldl (
                    \summen wert -> case summen of
                         []        -> [wert]
                         otherwise -> summen++[wert + last summen] ) []

Da foldl das Iterieren und Berechnen von neuen Werten aufgrund der iterierten Werten abstrahiert ist der Haskellcode im Vergleich zum C#-Beispiel ausdruckstärker. foldl ist somit ein Pattern welches in ähnlichen Situation wieder angewendet werden kann. Im Gegensatz zu einer for-Schleife in C# ist mit foldl die Absicht und das Funktionieren des Codes klar.

Lazy Evaluation
Mit Layz Evaluation sorgt der Intepreter dafür, dass ein Ausdruck erst dann ausgewertet wird wenn der Wert des Ausdrucks benötigt wird. Bei Haskell werden alle Ausdrücke standardmässig mit 'Lazy Evaluation' aufgelöst. Nur Dank dieser Technik ist es möglich mit unendlichen Listen zu arbeiten. Im folgenden Bespiel definiert die Funktion fibs alle Fibonacci-Zahlen. Mit der Funktion fibGT kann dann die erste Fibonacci-Zahl, welche grösser als ein bestimmter Wert ist, gefunden werden.

fibs :: [Integer]
fibs = [0,1]++[ a+b  (a,b) <- zip fibs (tail fibs) ]

fibGT :: Integer -> Integer
fibGT n = head (dropWhile (\a->a<n) fibs)

Bei C# werden standardmässig alle Ausdrücke sofort evaluiert und das Arbeiten mit z.B unendlichen Listen ist nur durch die explitzite Verwendung eines Iterators (IEnumerable, IEnumerator, etc.) möglich.

Pattern Matching
'Pattern Matching' hilft dabei, eine Funktion für verschiedene Fälle getrennt zu implementieren. So entscheidet der Haskell-Interpreter aufgrund der Argumente welche Funktionsimplementation für den aktuellen Fall herbeigezogen werden muss. So sind zum Bespiel folgende Funktionsdefinitionen für sumInt und sumInt2 gleichwertig:

sumInt :: [Integer] -> Integer
sumInt (n:ms) = n + sumInt ms
sumInt [] = 0

sumInt2 :: [Integer] -> Integer
sumInt2 ns = if ns == [] then 0
             else (head ns) + sumInt2 (tail ns)

Während in der Funktion sumInt für den Fall '(n:ms)' und den Fall '[]' zwei Implementationen gemacht wurden, wird in der Funktion sumInt2 alles innerhalb einer Implementation mit Hilfe von if-Entscheidungen behandelt.

Induktives Denken
Folgender Haskell-Code berechnet die Fibonacci-Zahlen (0,1,1,2,3,5,8,13,21...)

fibs :: [Integer]
fibs = [0,1]++[ a+b  (a,b) <- zip fibs (tail fibs) ]

Mich fasziniert an dieser Lösung, dass der Code nicht 'imperativ' als Anweisung verstanden werden kann. Der Haskell-Code oben lässt mich folgendes denken:

fibs liefert mir alle Fibonacci-Zahlen
Die Fibonacci-Zahlen beginnen mit 0 und 1
Die weiteren Zahlen berechne ich indem ich die Fibonacci-Reihe mit der um eins verschobenen Fibonacci-Reihe pro Zahl kombinieren und pro Kombination die Zahlen zusammenzähle.

Für mich ist diese Denkweise ungewohnt, da die Definition der Funktion fibs davon ausgeht dass fibs (bereits) die korrekten Fibonacci-Zahlen zurückliefert. Auch hat die Funktion deklarativen Charakter. Es werden nämlich nur die Berechnungsregeln beschrieben. Wie und wann welche Berechnung erfolgt ist nicht ersichtlich.

Model-View-Presenter (MVP) und seine Geschmacksrichtungen

2007-06-09T16:47:00.001+02:00

Neulich hat Jeremy D. Miller in seinem Blog die verschiedenen Ausprägungen des Model-View-Presenter Patterns erörtert. Hier ein kurze Zusammenfassung dessen was mir wichtig erscheint:

Dem MVP liegen im allgemeinen folgende Definitionen zu Grunde:

Model ist eine Abbildung dessen was dargestellt wird.
View ist die Darstellung.
Presenter bringt das Model auf der View zur Darstellung und aktualisiert das Model aufgrund von Benutzereingaben.

The Autonomous View

Das 'Anti-Pattern'. Model-View-Presenter sind in einer Klasse vereint.

Supervising Controller

Presenter: Übergibt das Model (oder Teile davon) der View zur Darstellung. Der Presenter wird von der View aufgerufen um auf Benutzereingaben zu reagieren.
View: bringt das vom Presenter an die View übergebenen Model zur Darstellung (z.B mit Databinding). Leitet Benutzereingaben an den Presenter weiter.

Die View ist somit direkt vom Modell abhängig.

Passive View

Presenter: Kapselt das Model gegenüber der View. Übernimmt das Databinding indem die dargestellten Werte (nicht das Model) explizit der View zur Darstellung übergeben werden. Der Presenter wird von der View aufgerufen um auf Benutzereingaben zu reagieren.
View: Stellt die vom Presenter übermittelten Werte dar und leitet Benutzereingaben an den Presenter weiter.

Gegenüber dem Supervising Controller Pattern hängt die View hier nicht vom Modell ab.

Presentation Model

Presentation Model: Das Model und der Presenter sind hier zusammengeführt. Das Presentation Model zeigt gegenüber der View die darzustellenden Werte und reagiert falls ein solcher Wert verändert wird. Das Presentation Model wird von der View aufgerufen um auf Benutzereingaben zu reagieren.
View: Bindet das Presentation Model direkt für die Darstellung.

Für die Kommunikation zwischen View und Presenter gibt es bei allen Pattern zwei Möglichkeiten:

Direkt: Die View ruft den Presenter direkt und explizit via Methoden auf (z.B im Eventhandler in der View).
Indirekt: Der Presenter abonniert Events welche die View zur Verfügung stellt.

Zur Zeit verwende ich meistens das Passiv View Pattern um eine höchstmögliche Testabdeckung in den Unittests zu erreichen.

LinqToSql vs. NHibernate

2007-06-07T18:48:00.000+02:00

Im folgenden vergleiche ich 'LINQ to SQL' mit NHibernate und Stelle die Unterschiede und Gemeinsamkeiten dieser beiden O/R-Mapper dar.

Sessions
Was in 'LINQ to SQL' der DataContext ist in NHibernate die Session. Beide Implementationen realisieren UnitOfWork und IdentityMap was uns ein sicheres und bequemes Arbeiten mit einem DomainModel ermöglicht.

Transaktionen und Locking
Da beide O/R-Mapper UnitOfWork implementieren, unterstützen uns beide auf ähnliche Weise beim optimistischen Locking. Beide O/R-Mapper halten den für das optimistische Locking nötigen Ursprungszustand der Objekte intern, also im DataContext oder in der Session.

Für das pessimistische Locking ermöglichen beide O/R-Mapper den Zugriff auf die Transaktion auf welcher der Transaktionsbeginn und -ende, sowie der Isolationslevel gesteuert werden kann.

Persistence Ignorance (PI)
Nur NHibernate ermöglicht das Persistieren von beliebigen Objekten. Bei 'LINQ to SQL' (in Orcas Beta1) muss INotifyPropertyChanging und INotifyPropertyChanged implementiert werden. In 'LINQ to SQL' kann wahlweise die Mapping-Information auf der Klasse als Attribute oder in einem externen XML abgelegt werden.

Eliminierung O/R Impedance-Mismatch
Hier zeigt sicher der größte Unterschied zwischen den beiden O/R-Mappern. Folgende nicht abgeschlossene Liste zeigt Features welche NHibernate unterstützt, 'LINQ to SQL' aber nicht:

Abfragen berücksichtigen unpersistierte Änderungen
Unterstützung mehrerer Abbildungsarten für die Vererbung ( table-per-class / table-per-subclasss / table-per-concrete-class )
Mapping von n-m Beziehung

Da 'LINQ to SQL' den Punkt 1. nicht unterstützt müsste zum Beispiel mit Aggregates (Eric Evans: Domain Driven Design) gearbeitet werden. Diese würden die unpersistierten Änderungen in ihrem Aggregate berücksichtigen und verwalten.

Abfragesprache
'LINQ to SQL' ist mit der Abfragesprache LINQ zur Zeit hier im Vorteil. Eine LINQ-Implementation für NHibernate ist aber in Bearbeitung und danach wird es unter diesem Punkte keine nennenswerte Unterschiede geben.

Wartung
Hier sehe ich keine grossen Unterschiede, da das Warten der Mapping-Informationen immer eine mühsame Angelegenheit ist. Mit dem 'LINQ to SQL' -Designer (Beta1) kann sehr schnell eine erste Version eines Mapping-Schemas erstellen werden. Die Wartung und Pflege des Schemas erfolgt danach aber manuell.

Falls jemand schon praktische Erfahrungen in einem grösseren Projekt mit 'LINQ to SQL' hat, würde ich mich über einen Erfahrungsbericht sehr freuen.

So nun muss ich mir noch LINQ To Entities anschauen!

Mein erster Blogeintrag

2007-05-30T19:37:00.000+02:00

Heute will ich meinen ersten Blogeintrag veröffentlichen. Ein Vorsatz der ich mir schon länger vorgenommen habe!

Als analytisch, vorsichtig und strukturiert denkender Mensch musste ich mir aber zuerst einige Fragen beantworten, bevor ich nun mit meinem ersten Blogeintrag starte.

Frage: Soll ich auf Englisch oder Deutsch schreiben?
Antwort: Ich schreibe auf Deutsch da mein Deutsch besser als mein Englisch ist. Falls ich jemals so schlaue Sachen schreiben werde dass es auch die "englische Welt" wissen sollte, wechsle ich die Sprache.

Frage: Über was schreibe ich?
Antwort: Ich schreibe über Softwareentwicklung wie ich sie verstehe, was ich davon verstanden habe oder was ich noch verstehen möchte. Ich schreibe hier über Softwareentwicklung da dies mein Job und einer meiner Leidenschaften ist. Falls ich damit die Welt verändern kann, werde ich vielleicht auch mal über Sachen sprechen welche mich persönlich beschäftigen.

Frage: Warum schreibe ich?
Antwort: Da ich schon immer das Bedürfnis hatte den anderen die Welt aus meiner Sicht und Überzeugung zu erklären. Und natürlich bin ich auch gespannt ob der Blog tatsächlich auch jemals von jemanden gelesen wird.

Also los ... mal schauen was daraus wird.

p geht zu f

2007-05-28T15:30:00.000+02:00

Mit der nächsten Version von .NET (Codename 'Orcas') werden wir tagtäglich mit Lambda-Ausdrücken arbeiten. Doch wie spricht man ein Lambda-Ausdruck überhaupt aus?

Was ist zum Beispiel mit p => f => f(p) ?

Wes Dyer vom C# Compiler Team spricht es in einem Interview als 'goes to' aus. In Englisch ist das also p goes to f goes to f(p). Ich finde dies in Ordnung aber beim Einsetzen der Variable f im Ausdruck f => f(p) finde ich das 'goes to' ungenau, da neben dem Binden der Variable f auch gleich die Funktionsapplikation f(p) stattfindet.

Eric White spricht in seinem Blogeintrag, abhängig von jeweiligen Kontext, von einem 'becomes' oder 'such that'.

Für das oben genannte Beispiel finde ich p goes to f becomes f(p) das Beste, weil der Lambda-Ausdruck in folgenden Schritten evaluiert wird:

'p => f' oder 'p goes to f', da nach dem Einsetzen der Variable p eine anonyme Methode resultiert welche p bindet und f als Parameter hat. In dem Sinne geht also p zu f, oder eben 'p goes to f'.
'f => f(p)' oder 'f becomes f(p)', da nach dem Einsetzen von f die Funktion f(p) ausgeführt wird. In dem Sinne wird als f in f(p) umgewandelt, was auf Englisch dann auch als 'f becomes f(p)' ausgesprochen werden kann.

Ich werde also in Zukunft das letzte '=>' als 'becomes' und alle vorangehenden '=>' als 'goes to' aussprechen.

Beispiele:

'a => b => a+b' ist 'a goes to b and becomes a+b'
'a => 1 + a' ist 'a becomes 1+a'