February 2006 - Posts
Accessessors in terms of getters and setters expose the internals of a class. Designing classes without concentrating on the accessors often lead to non-oo designs, aka procedural designs. Martin Fowler wrote an interesting blog entry GetterEradicator linking to interesting writings including GettersAndSetterMethodsAreEvil.
At the next meeting Olaf Conijn will demonstrate Enterprise Library for .NET Framework 2.0. Sign up here. Olaf is well known in the community for his excellent work on extensions.
Unfortunately I didn’t attend to the parallel session “Annotations/Attributes: How do they help us?” in Cortina, but ever since I worked on Declarative transactions at method level with Neo I’m intrigued by meta-data. Apparently Mats Helander suggested using class meta-data for class intent and map it against one or more frameworks (Mapping adds another layer of indirection and introduces its own set of challenges). Funny thing is that I’ve never realized the actual application design implications with using .NET attributes. It all became clear after talking with Erik Dörnenburg during dinner that using attributes for expressing the intention of transactional awareness off a class, is in concept similar to inheriting the ObjectContext class. As Arjen mentiones here, it is necessary to reference the assembly containing the attribute implementation. For Neo this typically means you’ll need to add a reference to System.EnterpriseServices.dll for all components downwards in your application stack. How will Mats’s proposition change our own future?
FYI, Erik will give a talk on Domain Annotations at the Spa 2006 conference.
Last week I have been one of the lucky few getting a glimpse of Martin Fowler’s new writing adventure. Martin discussed his current thinking about Event Patterns and in particular Event Sourcing in which all changes of the state in an application are bundled in event objects. Ordering these events in the same sequence they have been applied to the application enables us to roll everything back and all forward and thus to regenerate the application state. I believe that, while this design style is fairly common in the industrial automation domain, it is being underused in typical enterprise applications. This style of application design generates a lot of interesting opportunities. Martin asked for our experiences… below my best attempt.
For a tracking & tracing application it is very important to be able to answer the questions “what if this raw material is contaminated” and “where is the source of contamination given a (semi-finished) product”. To make such scenarios as transparent as possible before scheduling actual production capabilities and to reduce the risk for possible recalls, production plans are often simulated. The application generates production events for a given production plan and sends them to the production units. Virtualization software then virtualizes the production process on which scheduling optimization is executed. By using compensating production events (insert-only databases) and playback functionality operators can fine-tune the process even further. Expressing this type of behavior in software lends itself for Event/Event Sourcing Patterns.
|This week l've attended to a software architecture workshop held in Cortina, Italy. This year’s workshop was hosted by Andrea Provaglio (The Negotiator) who took over from Jimmy Nilsson (The Aggregator) who organized the first workshop in Malmö, Sweden and second in Lillehammer, Norway. We've discussed several interesting topics which I'll discuss in more detail in a future post(s). The great thing off this event is to share ideas with very smart people and to finally meet the faces behind the blogs. I think I have enough thoughts spinning through my head to keep myself busy for the next couple off months. At least as soon as I get over this pharyngitis which I brought back home with me. |