Ralf's Sudelbücher
-
ObjectSpaces questioned: Should object persistence really be thought of as orthogonal functionality?
I know, by asking the question in the subject line, some will view me as a haeretic or as naive or something else. But still, I cannot shed the feeling, that striving for this orthogonality - as Microsoft ObjectSpaces (OS) does - could be harmful. (For my exculpation let me say: since the early 90s I have been a fan of ODBMS and I very much like the thought of transparent object persistence. So I´m all in for a good O/R technology.)Why do I think so? Because I saw what happened to MTS and then COM+. Many developers did not understand, that designing classes to be run in an application server is different from designing class to be run in a rich client (aka winforms client). Microsoft made it too easy (!) to deploy almost any COM object in an app server application. People could do anything they liked, e.g. keep state, have properties in their app server classes. And that made them unhappy in the end, because performance often was low. But not due to a immature technology, but due to misuse.So I hope you can agree, that deployment in an app server is not completely orthogonal to the design of my classes. I need to forethink what I´m gonna do with my classes.The same is true, I now come to think more and more, for persistence. Let me say, at least in many cases. (Maybe sometimes orthogonality is really ok and even desirable. Applications for scientific labs come to my mind, which are more algorithm oriented that database oriented.)The cases, where I think, orthogonality is not desirable are the typical business applications, the ERP systems etc. Developers know exactly which classes will be filled from a database. They know their persistent objects from the start of the design on. And which objects need to be persisted does not likely change over the lifetime of an application.So, why should it be suggested to them: forget your knowledge? As long as they still need to explicitly persist changes and even register new objects with OS for change tracking, transparent persistence is not reached in imperative code. Why then should transparent persistence in deklarative code (type definitions) be so important?Because there already exist classes, whose objects all of a sudden need to be stored using OS? I doubt it. The amount of work to be done in code is still huge.Because it is so much easier to not think about persistence when designing a class and leave it to some other guy to come up with a mapping? I doubt it. It puts much burden on the persistence engine. And it keeps the gulf between OO world and relation world wide open, because it suggests: don´t talk to each other. You database guy, do whatever you want. And you OO guy, do whatever you want. My experience is, this leads to poor performance in the end, when trying to bridge the gap.Or because class design should not be tied to a certain persistence technology, be it OS or some other tool? Well, I guess, that´s the real driving force behind the orthogonality idea.But my feeling is, keeping class design absolutely clean and just spread mapping info across several resources, is the wrong solution.My suggestion would be instead: Give developers a "domain specific language" (DSL) for the definition of persistent classes. No, don´t try to do it in C#/VB.NET with attributes! Because then you would not be free to maybe sometimes derive from a PersistentObject base class. Instead persistent class should be defined in a special language hiding all implementation details from the developer.Like HTML is used as a special language compiled to IL in ASP.NET. HTML is a DSL for the realm of presentation layer programming. And we´re all pretty happy with that. So why not have a special language for data persistence programming?I also suggest, this DSL should not be a fully fledged programming language. No imperative code should be able to be written with it. Whatever business logic needs to be added to persistent classes (to make them less anemic ;-), can be added by derivation or aggregation later on.My conclusion: A DSL would not interfere with how objects are persisted in code. A DSL still would keep the definition of persistent types clean of any persistence tool specifica. A DSL would make it clear to a developer, he´s dealing with a persistent class. A DSL would help close the gap between OO world and relational world.From my experience what went wrong with the MTS/COM+ message, I´d love to see it done better for solutions to the object persistence problem. -
Three ADO.NET ObjectSpaces Newbie Problems Solved
When I started playing with Whidbey´s ADO.NET ObjectSpaces object persistence technology (see [1] for an introductory article) I immediately ran into two nasty problems costing me a long time to solve:
-
Making of dotnet.tv Folge 3 - Drehtagebuch Tag 6+7
Mit einem Tag Verzögerung ein kurzes Resumee der Produktion von dotnet.tv Folge 3:
-
Plan for VB3 to VB.NET/IL Converter
After a couple of meetings with clients still employing VB3 programms, I come to the conclusion, there is need for a "VB3 to .NET" migration tool. There´s still a lot (!) VB3 software running out there - and developers see no way to move it anywhere. Jumping onto the VB6 bandwaggon is not really the thing to do anymore - and an alternative is not in sight.
-
Making of dotnet.tv Folge 3 - Drehtagebuch Tag 5
Die äußerlich aufregenden Tage des Drehens sind vorbei. Heute haben wir mit dem Schneiden von dotnet.tv Folge 3 begonnen. Weniger Aufregung bedeutet das jedoch nicht. Fast im Gegenteil! Denn jetzt stoßen wir wieder in für uns unbekanntes Gebiet vor.
-
Making of dotnet.tv Folge 3 - Drehtagebuch Tag 4
Manchmal geht auch etwas schief. Heute zum Beispiel: nur noch magere 9 Szenen standen auf dem Zettel. Und alle sollten an einer Location gedreht werden, nämlich am Bildschirm.
-
Making of dotnet.tv Folge 3 - Drehtagebuch Tag 3
Auch ein Filmteam braucht mal ein wenig Ruhe. So hatten wir uns für heute nur 9 kleinere Szenen zum Drehen ausgesucht. Nach zweimal 2 Stunden an unterschiedlichen Drehorten war alles im Kasten.
-
Making of dotnet.tv Folge 3 - Drehtagebuch Tag 2
Geschafft. Der zweite Drehtag mit wieder 12 Stunden Arbeitszeit liegt hinter uns. Dass wir das Pensum in der Zeit wirklich hinter uns bringen können würden, hätte ich gestern eigentlich nicht gedacht. Es waren noch Szenen von gestern übrig, die wir nicht hatten drehen können, weil in der Lobby des Hilton immer wieder zuviel los war. Zusammen mit den für heute geplanten Szenen ergaben sich eine Zahl von 36 Einstellungen mit z.T. mehreren Abschnitten - gegenüber 28 am ersten Drehtag.
-
Making of dotnet.tv Folge 3 - Drehtagebuch Tag 1
Es ist wieder soweit: Die Dreharbeiten zur nächsten Folge von dotnet.tv haben begonnen. Und ich bin sehr erleichtert: sie gestalten sich in mancherlei Hinsicht leichter als gedacht. Aber der Reihe nach:
-
Enum login time of users on Windows machine to check for logged on user
In my previous posting ("Check for logged on user on Windows machine") I showed a WMI-based method to check, if a certain user was logged on. Andreas Häber then suggested in a comment, to use the Win32 API function NetUserEnum instead. Since WMI always sounds to me like a heavyweight technology, I liked the idea to resort to "simple" Win32 API calls to solve the problem. Below you find the result of my attempt wrapped in a VB.NET module.