March 2004 - Posts
Slashdot posted today a link to a photo journal of Chernobyl, made by a Ukrain girl called Elena who went back to the Chernobyl area, 18 years after the nuclear disaster. This is a good example of the true power of the Internet: real journalism, real facts and available to everybody worldwide.
The journal is very moving, especially to the end. I'll link to mirrors to save her bandwith. Mirror 1. Mirror 2.
I've been fighting this bug all day and it annoyes me more with every minute I spend on it. Here's the deal: I have a ListView control and a Textbox control on a winforms form (.NET 1.1). With the Textbox you can edit a field of the object on the current selected row in the ListView. Easy right? I thought so too 
.
Not all values filled into the Textbox are valid. So I added a handler of the Validating event of the Textbox. When I tab away from the Textbox, the event gets fired and validation kicks in. If validation succeeds, the value is set in the object, otherwise validation fails and focus stays with the Textbox. When the SelectedIndex changes in the ListView and there is still a row selected, I fill the Textbox with the value of the particular field of the object currently being selected. This should work as Validating always should kick in when focus moves away from the Textbox.
But now the misery begins. Question: in which order are the following events fired when I'm editing the text of the Textbox and I click on another row in the ListView control: Textbox.Validating, Textbox.Leave, ListView.SelectedIndexChanged?
Answer: ListView.SelectedIndexChanged, Textbox.Leave, Textbox.Validating. 
I'm sorry, but this is semantically wrong. What if validation fails? Focus should never move away from the Textbox before the Validating event. I now have to write some code which I consider a hack to work around this by keeping track of which object was previously selected in the ListView and I can't overwrite the 'currently selected row' when an edit is in progress, however I have to store somewhere that there is now a new selected object so after validation succeeds I have to set the Textbox to a new value.
When events were fired in the right order, this would be all fine. The low level reason for this error is the asynchronous behaviour of winform controls: under the hood they're (most of the time, there are exceptions) Win32 controls which solely respond to Win32 messages. So if you click on the ListView, the control receives a message from Windows, it acts on it and fires an event. Focus moves away from the Textbox after this and this will cause a message to be delivered for the Textbox, which will cause a .NET event. But much too late.
So if you set up a similar setup, be aware of this. 
For all the people who think the EU ruling in the Microsoft case is about Realplayer vs. Windows Media Player: you don't get it.
It's not about some crappy player vs. some other crappy player program. It's about the difference between integrating a program into an OS and shipping a program with an OS. In both occasions the user will not see the difference, as in both occasions the program is in the start menu. The difference is in the fact that the real (pun intended) customers of Windows (the OEM's) should be able to decide which package of extra software they ship with the OS. They can in the situation where the programs are not integrated with the OS. They can't when the programs are part of the OS.
I haven't read anyone debating the obvious question: why did Microsoft integrate WMP into Windows and why wasn't WMP made a separate program? The answer is pretty simple. When you start WMP in its default form, you are, when connected to the net, automatically visiting which website? Ok, and what can you do on that website? Buy music! But that's not all. You can also listen to content delivered by 3rd parties, the so called 'partners'. That content is streamed to you in MP3 format, or any other format than WMP's native formats? No, WMP native.
Now here's the catch: WMP is a tool to get people onto sites where they can spend money and it is also a tool to get as much content providers use the WMP native formats. You see: if more and more people have WMP installed on their system, more and more content providers will obviously provide their content in WMP native formats so the largest possible group of people can consume the content.
Who will benefit from that, financially? Who can sell WMP streaming servers to the content providers? (They happen to come with a nice Windows 2003 installer 
) Who can sub-license their streaming technology to 3rd parties because it will be the de-facto standard, because every consumer has the player right there on their desktop?
This is Big Money PoliticsTM, people. Who has the media, has the people. Today people watch content on their TV. within a few years more and more content will be made available via the Internet via streaming technology.
Do you still think this is about a silly player vs. silly player debate? If you still do, go back to the top of this article and start reading. Until you get it.
(disclaimer: I don't use either one of them, I use Winamp 5)
Dan Fernandez blogs about the Whidbey release date slip and VS.NET service packs. An understandable article and I thank him for giving some insights in the why-o-why's. He also talks about service packs and why this is a problem. He gives some reasons why service packs for VS.NET aren't released yet. Let me warn you first: reading the reasons may cause you to fall of your chair so grab your desk or other strong, solid piece of material to avoid you getting hurt. Please acknowledge that Dan is most likely not the origin of these statements so a "Don't kill the messenger" is appropriate.
Ready? Ok, here we go. I commented on his reasoning below his comments.
WRT your point about why there have been no service packs for VS, first realize that we have several hotfixes up at http://support.microsoft.com if you have a particular problem to address, feel free to contact me directly.
This is absolutely bogus. Here's why:
Say there is a bug which I need fixing for my own software to work correctly. Am I helped with a fix from PSS? No! My own install perhaps works with the fix, but my customers who will use my software have to call PSS as well!
An ISV can't rely on that: "To get this piece of software working, you first have to call Microsoft for a fix". Most customers don't want to install hotfixes for .NET, they want service packs for .NET. That's why a hotfix is nice for an internal application, however for ISV's it's absolutely not usable: they can't ship the software with the patch, the customers have to call MS themselves.
I appreciate the time you want to take, Dan, to fix bugs or communicate between developer and MS developer but please realize that hotfixes are unusable for ISV's for the reason I just mentioned. Support like this is not to be called support. Sorry that I might sound a little annoyed but as a matter of fact I am annoyed about this issue. I'm getting pretty tired of all the blabla coming from MS about that there is no issue with support, that customers get the best support possible etc. while a massive amount of developers complaints about this day in day out (read the newsgroups f.e.). So, please please please realize what the pains of the developer community are today so please address them a.s.a.p.
You can read all about the developer implications of Windows XP SP2 here. I don't work on the Visual Studio servicing side (anyone who does chime in here), so I'm just giving you an educated guess here, but since there are specific developer implications for Windows XP SP2, the VS team would need to factor/depend on those changes for any future Visual Studio service packs.
This is pure CoverYourAss.exe, pardon my French. It's not my nor anyone elses problem that the design of Visual Studio apparently relies on Windows XP's structure and changes made to WindowsXP seem to break Visual Studio.NET. Furthermore, VS.NET and .NET 1.1 were released in April 2003 (!). That's almost a year ago. Are you trying to sell me the idea that in that year all bugfixing effort has been put on hold because of an XP service pack coming later this year? I hope not
A lot of bugs are already fixed, for a long time (hotfixes are available if you call PSS, but not for the public), however they're not released to the public. What's wrong with: release the fixes now and release another fix for XP SP2 when it arrives? Why o why do we have to wait till Q4 2004 before any fix for vs.net 2003 or .NET 1.1 are released?
Let me take a wild guess: fixing stuff costs money and time. Putting developers on those fixes now is not productive because they can better work on Whidbey as it is behind schedule as it seems. Understandable, but again, not the problem of the customer. The customer (the developer using VS.NET and .NET 1.1, you know, the people who do the hard work for Microsoft to get .NET accepted in the real world) payed for software and wants support, because s/he has every right to get support in the form of fixes.
I know that this rant will not make any difference, but so be it, at least some people now know the other side of the story.
eWeek has an article about the release date slip of Yukon and Whidbey. It's more an article about Yukon than about Whidbey and for a reason: it's a known fact that Yukon holds back Whidbey, not the other way around, so if Yukon slips, Whidbey will slipperdy slide with it.
From the article:
According to Rizzo, both products are on the same timeframe for shipping for a key reason: Namely, Microsoft wants to release the best of its developer tools with the best of its database technology "to really change the industry," he said. "If you look at Oracle [Corp.] and IBM and other competitors in the open-source space, they don't have releases where new and innovative tools are released with a new and innovative database. Customers want that: the next generation of tools that exploit the next generation of database technology."
This re-vamped some thoughts I have had for a long time: is it truly a Good ThingTM that Yukon and Whidbey are released at the same time? And if it is a good thing, for whom is it 'good' and for whom is it less 'good' ?
Let me say it my way: it is a good thing for Microsoft and a bad thing for developers.
The reason for this is: developers really need an update to Visual Studio. Because Visual Studio.NET is tied to a particular .NET version, a slip of the VS.NET release date will also make .NET 2.0 slip further away. Due to the current not-all-that-bugfree state of the VS.NET 2003 IDE, it is key that developers get their hands on Whidbey a.s.a.p. Talk to an ASP.NET developer and you know why. Talk to people who want to get started with generics and better editors and you know why. Furthermore, do all those developers write software targeting SqlServer and do they need VS.NET to target SqlServer? I don't think they all do. So do they really need Yukon together with an update of VS.NET? No, not at all. Only if they've decided to target Yukon. If they have to work with a production SqlServer 2000 or even SqlServer 7 or Oracle 8i/9i system, they don't need Yukon at all. But they do need Whidbey because of the vast amount of improvements and bugfixes.
Why is it a good thing for Microsoft? To tie Visual Studio.NET with Yukon, Visual Studio.NET can increase Yukon sales. Visual Studio.NET is the tool used the most for .NET development. If Visual Studio.NET has by far the best integration with Yukon compared to Oracle or DB2, it might be an extra benefit for Yukon so project teams might decide to opt for Yukon instead of the competition.
Looking at the marriage between Yukon and Whidbey, I can only say: stop the councilling, get a divorce and start seeing other people, because it will only affect the happiness of the children and friends. It's nice that Microsoft tries to make more money by pushing Yukon through Whidbey, but for developers, a development environment is a toolset used to write software, not an extension of 'a' database. However, because of delays in the Yukon department, Whidbey is delayed too, which is very sad news for .NET-targeting developers.
Other sad news is that MS apparently has cut some serious enterprise features from Yukon. It might look like a lot of SqlServer users don't need serious enterprise features, but current users of Oracle and DB2 on big machines do need those features, however are of course not very eager to migrate to Yukon if they have to drop serious enterprise features for that because Yukon doesn't support them. I really wonder why MS can't pull it off. Yukon is already more than 5 years in development, SqlServer 2000 wasn't and still isn't a bad database, so what's the showstopper in Yukon that it is delayed so much? Is it CLR integration? Or is it something else? I find it bad news that MS can't get Yukon ready on time, because it means that development was problematic which can only lead to a problematic end result. Because I like SqlServer, that's not something I'm looking forward to.
Perhaps MS could consider releasing an SqlServer 2000 SE version with just MVCC features, a better toolset and an earlier release date of Whidbey, thus ending the marriage between Yukon and Whidbey for good.
Paul Wilson and Alex Thissen both blog about concurrency control related to O/R mappers. Let me start by pointing you to an article about concurrency methods I wrote some time ago: Concurrency Control Methods: is there a silver bullet?. I don't believe in low level concurrency methods, as they give you the false sense of 'it has been taken care of', while they just don't do that: they still cause loss of work.
However, there are occasions where low level concurrency control can be helpful: for example if you don't care if someone looses his/her work and you just care about the consistent state of the database, or in situations where you for example want to prevent deletion of data after some period of time (user opens edit screen, goes away for lunch, comes back, deletes data, however the state of the record has been changed, the delete should not happen). This example also illustrates that concurrency control is not something that's solely related to saving data. It is also related to deleting data.
In my commercial O/R mapper LLBLGen Pro I had to solve the same question Paul Wilson had asked himself: how to implement concurrency control? History learns that when you ask a random group of developers: "how would you implement optimistic concurrency control?", you get a wide variety of answers. This means that, besides the point that there is no silver bullet to solve all concurrency problems, it is also not possible to define a common way to supply concurrency control: different developers will implement concurrency control differently, or at least: want to use it differently.
In LLBLGen Pro I've solved it by introducing a predicate factory which is used through the Strategy Pattern [GoF]. A predicate is a clause which can be used in a WHERE statement of a select or delete. The factory implements a common interface: IConcurrencyPredicateFactory, defined as follows:
public interface IConcurrencyPredicateFactory
{
IPredicateExpression CreatePredicate(
ConcurrencyPredicateType predicateTypeToCreate,
object containingEntity);
}
where ConcurrencyPredicateType is a normal Enum.
A developer who wants to add concurrency control to a given entity, can implement this interface and store an instance of that implementation in the entity instance. Once that is done, persistence logic, like the Save logic or Delete logic, also during recursive saves (saving a complete hierarchy of objects at once in a single transaction) will consult the IConcurrencyPredicateFactory instance for a predicate to add to the filter to be used in the Save or Delete action. Because the predicate is constructed at runtime, in a class the developer writes him/herself, the predicate can be constructed precisely how the developer wants it to be. The factory can even fire events, call delegates or consult other objects to retrieve information to produce the correct predicate expression, because the class is written by the developer, it just has to implement the one method defined in the interface.
Discussions how concurrency control has to be implemented are then not necessary anymore: the developer decides. Customer requires timestamp-based concurrency control and Order requires all-value-checking concurrency control? Just produce the predicate expression which matches those requirements: pass a different implementation of IConcurrencyPredicateFactory to the Customer entities than you pass to the Order entities. Concurrency control as flexible as you can possibly get, and usable not only on a per-type basis but also on a per-instance basis.
Steve Eichert blogs about the question if we need an Object-Message mapper (O/M mapper he calls them) in a Service Oriented Architecture (SOA) world. It's my understanding that he thinks we need an O/M mapper when we're going to use SOA. I beg to differ.
A couple of months ago, in the microsoft.public.objectspaces newsgroup a lengthy discussion was held about the topic 'Is an O/R mapper useful in a SOA world?'. The reason for this discussion was of course: how will O/R mappers be affected once SOA is widely accepted as a solid architecture for building software systems. It turned out that the Domain Model-followers (let me call these 'Fowler followers') said that SOA would affect O/R mapper usage and the people who see advantages in the Manager Model (separate classes which solely process data passed in, like an 'OrderManager'. Often mimicing business processes on a rough 1:1 basis) didn't see that happen.
When you use the Domain Model, you (generally speaking) define business logic in your entity classes through inheritance and/or aggregation. This means that you add for example business logic related to customer entities to the customer entity itself. The average result of this is that the vast majority of your application's business logic layer's API is formed by the set of Domain Model classes ('Domains') you've defined. A problem arises when you want to make this API a service which has to be used by other tiers in your application, for example a set of GUI tiers on desktops and webservers. Communication between these tiers and the 'service' requires that you can map messages used to communicate between client and service (or service and service) onto the entity objects defined. In a sense, this can require a tool to make this an easy task: an O/M mapper.
When you use the Manager Model, you don't have to. The reason for that is simple: a 'Manager' in the Manager Model acts as a service by itself, it's the task of the Manager in a Manager model to provide a service. This means that you use the service in a more procedural way, like you are doing today with a webservice. Data passed between client and service (in this case the Manager or for example a 'Manager manager' or 'Manager dispatcher') or service and service can contain entity objects, but also data which will be transformed into entities inside Managers. Does this require an O/M mapper per se? No, not at all. A tool to connect method call to method definition is more appropriate, thus a tool which will be used to design the SOA architecture.
It thus depends on how you design your software in general: do you want to use your entity objects 'by value' (and thus do you want to apply logic on them by passing them to a service object like a Manager) or do you want to use a rich Domain Model where the entities are used 'by reference' because they form the service?
Thinking about this, I come to the conclusion that the question is not: do we need O/M mappers in the SOA world, but: do we need the Domain Model in the SOA world? With the advantages of easy projection of functional descriptions of business processes on Manager Model classes in the hand, with the absence of the necessity of yet another tool to map data to objects (because in the Manager Model, the SOA architecture tool will be sufficient), I can only say: for me, we don't need the Domain Model in the SOA world. We can do just fine using the Manager Model approach, which doesn't suffer from the disadvantages the Domain Model brings to the table in a SOA approach. This doesn't mean the Domain Model doesn't have a place in the software world, it's my conclusion that the Domain Model (and thus O/M mappers) do not fit SOA and if you want to use a SOA-oriented approach, it's thus best to use the Manager Model instead of the Domain Model
CodeAse has changed the documentation and application they based on my code so it now shows the right copyright clause as stated in the BSD2 license which was shipped with the original LLBLGen 1.x sourcecode they based their product on. The earlier reported license violation (and thus code theft) is hereby solved.
I'd like to thank all of you who have supported me with this issue. Thanks!
More Posts