Castle is an open source project for .net that aspires to simplify the development of enterprise and web applications. Offering a set of tools (working together or independently) and integration with others open source projects, Castle helps you get more done with less code and in less time.

Het bevat o.a. support voor een MVC web framework (MonoRail), dependency injection (MicroKernel, Windsor Container) & een ORM mapper (ActiveRecord).

Core 1.2

Het hoofd component van het framework. In deze versie is het Email Sender component en de Logging service geintegreerd.

MicroKernel/Windsor 2.1.1

Dit is het dependency injection component van het Castle Framework. De nieuwe features zijn:

• Type forwarding
• Support for lazy loading van components
• Performance improvements

ActiveRecord 2.1

Dit is het ORM component van het Castle Framework. De nieuwe features zijn:

• Bijgewerkt met versie 2.1.4 van NHibernate
• ActiveRecord bepaald nu zelf op basis van het type wat de primary key generator moet zijn.
• Support voor read-only properties, hiermee kun je door de database gegenereerde waardes in je object beschikbaar maken.

Bronnen:

http://kozmic.pl/archive/2010/01/12/castle-windsor-2.1-dynamic-proxy-2.2-and-more-released.aspx
http://mortslikeus.blogspot.com/2010/01/activerecord-21-released.html

Eergisteren is de nieuwste versie van Mono gereleased. Het open source alternatief voor het Microsoft .NET framework is aangeland op versie 2.6. De kern van deze release is de debugger en cross platform.

De belangrijkste nieuwe features zijn:

• Windows Communication Foundation subset zoals beschikbaar voor Silverlight 2.0
• LINQ to SQL
• De nieuwe debugger geintegreerd met MonoDevelop
• Inclusief de door Microsoft open source gemaakte versies van ASP.NET MVC, ASP.NET AJAX en de Dynamic Language Runtime
• En natuurlijk zijn verbetering op het gebied van performance en compatibiliteit met de Microsoft .NET API

Daarnaast is er een nieuwe versie van de populaire tegenhanger van Visual Studio gereleased: MonoDevelop 2.2. De belangrijkste features van deze nieuwe versie zijn:

• Ingebouwde debugger
• Refactor mogelijkheden (Inline rename, extract method, sort usings, etc.)
• Grafische interface is verbeterd
• Support voor ASP.NET MVC en T4 ontwikkeling

Het originele pers berich is te vinden op: http://www.mono-project.com/news/archive/2009/Dec-15.html

Zijn er al early adopters die hun mening willen delen? Plaats een reactie en laat het ons weten!

Vaak een heeft een state transitie in het domein wel een betekenis. Ik wil bijvoorbeeld zodra er een artikel gepubliceerd is ook een notificatie e-mail uit laten gaan. Je wilt in dit geval dat je applicatie met een expliciete state transitie.

De welbekende blogger Ayende Rahien heeft een mooi stuk over dit ontwerp geschreven op zijn weblog. Zijn stuk is zeker de moeite waard om te lezen.

Voor het uitwerken van enkele onderdelen kan het nodig  zijn dat een architect of developer aanvullend onderzoek moet doen. ..Dit is vaak nodig bij complexe onderdelen binnen een site die zeer specialistische kennis behoeven. Deze uitgewerkte onderzoeken worden vastgelegd in een technisch ontwerp. Hierin staat HOE bepaalde onderdelen technisch gerealiseerd gaan worden. Een technisch ontwerp wordt geschreven door een zeer ervaren developer of architect en is een document dat voor en door developers (en eventueel techneuten bij de opdrachtgever/klant) wordt gemaakt.  Nadeel: het is helaas vaak onbegrijpelijk voor de klant, dus is er minder begrip voor de kosten die hiermee gemoeid zijn., echter…:

Ontwerp is essentieel

In de ontwerpfase worden juist de belangrijke beslissingen genomen als het gaat over de essentiële onderdelen van een website of webapplicatie.  Je beslist hier immers over de fundering van de site , en zoals bekend, deze kan maar beter goed in orde zijn. (Hier falen veel ict-projecten jammergenoeg).  Afhankelijk van het project zal de behoefte aan technisch ontwerp voor de te bouwen onderdelen erg verschillen. Vaak moet een website worden gebouwd en gekoppeld in zijn eigen unieke omgeving, en het is daarom lastig om eenduidig te omschrijven welke onderdelen er in een technisch ontwerp moeten komen. Onderstaande geef ik een aantal voorbeelden waar gedacht kan worden:

Inhoud technisch ontwerp

De volgende zaken kunnen worden uitgewerkt in een technisch ontwerp (en is zeker niet uitputtend)

• Architectuur van de site (Hoe richt je de code van de applicatie in?)
• Performance (hoe garandeer je de performance van de site bij grote bezoekersaantallen)
• Caching (hoe is de caching van pagina’s of onderdelen in de site geregeld)
• Databaseontwerp  (welke data moet er opgeslagen en hoe is deze aan elkaar gerelateerd)
• Datamodellen van entiteiten binnen de site (Welke velden heeft een user in de site of een bestelling)
• Imports  (mapping van velden vanuit de de te importeren content naar de database)
• Beveiligingsmodel (welke rollen en rechten, wie mag waarbij)
• Koppeling met een andere applicatie ( bv een CRM of SAP )
• Zoekfunctionaliteit (welke zoekmachine wordt er gebruikt, hoe wordt er geïndexeerd)

Ook voor deze voorbeeldlijst geld: het kan zijn dat niet elk onderdeel benodigd is binnen je eigen project of website!
Gebruik bovenstaande als checklist of als inspiratie om binnen je eigen project de onderdelen te identificeren.

Investeer en bespaar geld

Gebruik bovenstaande lijst als een checklist om jezelf ervan te vergewissen dat je in de loop van het project niet met deze zaken te maken krijgt.  Zijn ze echter wel nodig, investeer dan in deze documentatie. Je moet deze zaken vooraf tackelen om grote kostenposten in het project later te voorkomen. Onthoud, deze zaken staan aan de basis van de site, dus als je hier iets in moet gaan veranderen tijdens of na het project, houd dan rekening met een grotere kostenpost!

Lange termijn

Daarnaast, denk je eens in dat de applicatie nog een keer gebouwd moet worden in een andere techniek. Dan is het wel zo prettig als je bouwdocumentatie hebt van de huidige applicatie (waar je in al die jaren tijd dat de site live heeft gestaan ongetwijfeld veel tegenaan hebt gebouwd).Vooraf nadenken levert net zoals bij het functioneel ontwerp ook hier wederom vele voordelen: onderhoudbaarheid van de applicatie, kwaliteit van de code,  kosten van wijzigingen vallen lager uit, je voorkomt performance problemen en tal van andere issues waar je anders mee te maken kan krijgen. Doe er dus je voordeel mee. Samengevat:  in het FO staat WAT je bouwt, in het TO voor de lastige onderdelen HOE je het bouwt.

Dit artikel werd eerder gepubliceerd op Publishr in de reeks: “Websites op maat in het watervalmodel“