July 2005 - Posts
Normally it's not a big issue having only single inheritance in the .NET languages. Unless you want to add a set of common features to the controls that Microsoft gives us...
I ran into this in a previous project where we rebuilt an existing application in .NET/C#. One of the features of this application was that controls like TextBox and ComboBox could have different colors depending on the state of certain data. For example: if it was a new entry some fields would have a green background to show that they were mandatory; others were yellow or white. As the state changed (i.e. fields were given a value), their controls switched colors too...
Well, you could of course code this into all Forms (yuck...that's no design), create your own control library (are you out of your mind?), convince your customer that this behavior is something you've never seen before and is impossible to build in .NET...or remember the days of VB6 and its 'inheritance' of classes.
In VB you could use the properties and methods of a class A in another class B by adding a member of type A in class B and make this one publicly visible with a property.
' Class A code
Private Sub Class_Initialize()
' Constructor of class A
End Sub
Private Sub Class_Terminate()
' Destructor of class A
End Sub
Public Sub CoolFeature()
' Do some cool stuff
End Sub
' Class B code
Private m_instanceOfA As ClassA
Private Sub Class_Initialize()
' Constructor of class B
m_instanceOfA = New ClassA
End Sub
Private Sub Class_Terminate()
' Destructor of class B
End Sub
Public Property Get instanceOfA() As ClassA
Set instanceOfA = m_instanceOfA
End Property
Then you could do things like Dim x as B and call x.instanceOfA.someFunctionOfA
' Application code
Sub Main()
Dim b As ClassB
Set b = New ClassB
Call b.instanceOfA.CoolFeature
End Sub
With this in mind, the idea of Extension classes was born. An Extension class is responsible for implementing some common features. Further, you can inherit from an Extension class to extend it. It look a bit like a Decorator pattern (http://www.dofactory.com/Patterns/PatternDecorator.aspx), except that you don't create the Decorator classes yourself, but your derived control class does in its constructor.
I created a tree of Extension classes starting with:
- an abstract base class ExtensionBase as the root class with general properties and behavior (like storing a reference to the Control)
- an Extension class for implementing common features for all control types (like setting colors, bordertype)
- a TextExtension class derived for specific TextBox related features (like regular expression validation on leaving the control)
- a CheckBoxExtension class to translate values coming from a datasource into check or unchecked state and back
- a MenuExtension class for menu-like controls (we used an ExplorerBar control with expanding panels and clickable items to start tasks...like the XP UI)
- and so on.
In the constructor of an Extension class the control is passed as Control type. The instance of the Extension class stores this reference internally in a private member. This way the Extension class instance can invoke methods and use properties of the control in which it sits as a member (well, most of the time you have to cast to the appropriate control class type to do that but why is the 'is' operator invented if you're not gonna use it...)
The controls we used were derived from the control class of the Framework to inherit the default behavior. They also got one or more Extension class members to add new behavior. Finally, by adding public properties and methods to the derived controls classes, the extra features were exposed publicly so that you can program something like
MyTextBox t = new MyTextBox(); t.SomeNewCoolFeature();
These properties and methods simple route to the Extension class member inside to do the job. Also, some events (like Validating) of the derived control classes were linked to a method on the Extension class to implement common behavior for them at 1 place.
Now why didn't I use the Framework's extension possibilities. There is an example which builds a HelpLabel control. Well, I looked at it and decided it would be too much work to do it that way, because your control class has to implement an interface and then the implementation of the extra features still sits in each control's implementation class. I could have put that in a normal class and route to that but what's the point of putting the interface on the control class then?
The final day: I think the one with the highest session score
Starting with my first WinForms session WCD324 by Brian Noyes of IDesign.
Lots of demo's on new controls (menu's, DataGridView, BackgroundWorkerProcess). Databinding got a lot better, and got extensible by the INotifyPropertyChanged interface. The DataGridView is a combination of the DataGrid and ListView. Easy setup with designer, virtual mode for computed columns (fires an event per cell to set the value). Layout controls make us grow to the way you layout ASP pages (and Avalon in the future): just draw a table on your form and put controls into it. Also FlowLayout possible and a decent SplitContainer to replace the Splitter control that had its quirks when you put the controls in the wrong order on the Form. Also WinForms are easly localizable (property on the Form plus resources). And your get UserSettings (read an writeable) next to AppSettings. Strongly types classes are generated now for these configuration files so you can program like AppSettings.MySetting = some value instead of the ugly and error prone AppSettings["MySetting"] syntax
After that DEV466 on the new Source Control features of TeamSystem. A great step forward compared to Visual SourceSafe
- data stored in database
- web accessible
- multiple client platforms possible (demo of Linux based SourceGear's Allerton checking sources out, changing them and checkin)
- local cache for retrieved files
- diff tool extensibility
- checkin policies (on system, project, file)
- workitem integration: specify your Project Server task when checking out to get traceability of changes
- shelving: put your current work on a shelf, get a prevouis fileset, fix stuff, unshelve and go on
- delta file storage
- email checkin notification
- shared checkout and merging
- VS.2003 integration (RTM version only so not Beta2)
- NOT: keyword expansion, pinning and sharing, shadow folders
Just before lunch the ARC412 by Maarten Mullender on Designing for Concurrency. Maarten is not a CRUD lover and he explains why.
Design for concurrency is about reducing the risk and impacts of concurrent changes in your system's data. He uses the metaphor of Venetian Bankers who use a Journal to log all changes and then (at a later time) update accounts from the logged entries. This means that these recordings are not overwritten, the log just grows.
Some of his recommendations:
- Use a Journal Pattern in your design. Entries in the log must be identified uniquely, can have an expiry date, combine business related actions into a single document (there's the document centric desgin again), can be sent as request to a service, are never changed, just add corrections.
- Specify guarantees or expected behavoir (like an SLA or mortgage offer)
- Uniquely identify requests: to preserve double sending and handling of the same message
- Make sure your lies are qualified (compare with a local cache: how long is the data there still valid)
I just wonder why different speakers use this document centric approach. Last year at the smart client track I heard that Microsoft also sees a future for their Office products an UI to call services...is this their way to sell more Office licence in the future? By designing them into solutions...
We'll see next year at Tech-Ed 2006 I guess
After lunch the CTS440 session of Brian Noyes on Smart Client Offline Data Synchronisation waited. Nice story on what possiblities you have to solve these issues when working with offline data. Also a look into the Offline Building Block of the Patterns and Practices group
Then the final CTS465 session by Christian Weyer on choosing your aproach to desing web services with .NET. Again a talk on how to avoid the pitfalls when you need to build interoperable services and a plead for the contract first design tactic. See the slides, I was tired of writing stuff down.
Day 3 starts with CTS360: how to do asynchronous messaging (not so complicated according to presenter Clemens Vasters). Interesting presentation on how to combine webservices calls with MSMQ (no WSE)
Then CTS366: Indigo again, this time on Secure, Reliable, Transacted messaging. More on the configuration to get these things going by Steve Swartz and Ingo Rammer
As I do not have enough of this stuff, a CHT031 on the implications of Indigo in Service Oriented Architecturing. Well, more a quest what that A means in SOA and if it's there by purpose or just a salespoint. The end of the discussion got a bit more practical: whether enterprise wide datamodels were good or not (as with services we can get different views on presumably the same concepts: e.g. a customer has totally different properties according to the sales department than to the financials department)
After lunch ARC419: the greay area of implementing Services using OO technologies. Nice talk of Beat Schwegler on how things just might not be what you expect when building service oriented systems with object oriented tools / languages. Great examples on the consequenses of renaming parameters of a web method (breaks the generated contract if you did not use [XmlAttribute(...)] in the code to set these to a fixed name for the outside world!) and the different encoding standards that you can use for the SOAP message (use doc-literal and not rpc-literal /rpc-encoded like the Java world uses a lot if possible).
In the ARC mood to ARC313: Patterns for Service Oriented Architecture by Ron Jacobs. Great joke about Bill Gates...4 tenets revisited, then some things to watch out for:
- loosy-goosy: why you don't want flexible interfaces like QueryDB(sqlstatement, databasename) and ExecThis(cmd, args); question here is what is your contract (i.e. what is this service going to do for you and will that still be the same in 1 year)
- cruddy-interfaces: this leads to chatty interfaces, rpc-style of development, statefull interaction (a MoveNext() webservice on a previoulsy openend DataSet); and possibly methods that leave your data in an inconsistent state.
Well, what to do then?
- Encourage document centric thinking. A lot of business processes are about handling documents. So why not use that in our software...by defining request - response message schemas
- Define clear semantic in the contract (what do we mean by ...)
- Promote loose coupling by encapsulation of implementation: use no platform specific datatypes in the contract (Java does not know .NET System.Data.DataSet)
- Be easy to consume from any platform (use WS-I base profile)
- Generate objects from schema (XMLObject generator tool downloadable)
- Services should encapsulate a complete unit of work (avoid chatty interfaces)
- What about transactions: don't share distributed transactions, you surrender precious resources to possible untrusted parties
- Compensational actions are OK, but don't rely on the consumer to do these (be in control yourself)
- Use the reservation pattern
Finally I closed the day with CTS358 by Juval Lowy on System.Transactions
In the 1.0 / 1.1 Framework explicit transactions are most suitable for single objects in a single database. If you have multiple objects and multiple databases, you're stuck with EnterpriseServices, DTC, object disposal at the end of the transaction and single-threading
The 2.0 Framework unifies the programming model. The developer does not have to choose, the Framework uses the apropriate technique withing the transaction's scope. So you create a TransactionScope object and within that do your transactional work. A try...catch around this block catches all errors (so not scattered around in different objects that are used within the transaction's scope).
Nesting of scopes is supported (directly so within a method, or indirectly so scattered over multiple objects), as is automatic enlistment (in case of transactions over multiple databases). The enlistment features only works for SQL2005...
A final thought of Juval was the use of the exensibility features here: you can define your own transactional datatypes. He showed us a transactional collection and array. Imagine the programming wealth you get when every datatypewould have a Rollback method to und changes...well, maybe in version 4.0 of the Framework.
Day 2 starts with the first keynote: not as spectacular as last year (no african drum sessions) but real life situations comedy to point out Microsofts efforts to help companies doing their work more efficiently.
After that the ARC302 session about building and using software factories: you can extend Visual Studio 2005 the make the developer's work easier by providing guidance and code generation tools. Impressive, but needs some thinking before you start your project. We knew that already from the Rational environment in Resu!t. Setup your project first, then start working.
Then the CTS349 session about Beyond WSE: what the wizard doesn't do for you but needs to be done. Understanding the configuration settings when you're using Web Services Enhancements. See her blog on www.dasblonde.net
Well, I'm getting in the mood with CTS265: Address, Binding and Contract: the ABC of Indigo endpoint configuration. The configuration part of the ODBC for using services (as I like to think of Indigo). The Indigo programming model simplifies the usage of the diverse techniques that Microsoft offers today for doing remote procedure calling and stuff like that: web services, .NET remoting, EnterpriseServices (a.k.a. COM/DCOM from .NET) and MSMQ. In your code you only use the Indigo classes, your configuration describes the technique to use and the framework uses that.
Finally DAT331: report auditing with Reporting Designer. A 1 hour demo of this tool, which will be usable without the complete Visual Studio environment to create reports with Reporting Services. Forget the slides, they'll show only the presenters info and DEMO a couple of times.
This time a relaxed start with SRV400 about what Windows is doing while Task Manager shows 100% Idle process time. Interesting talk by David Solomon of SysInternals on how to find your where Windows spends your precious time mainly using their ProcesExplorer tool.
Then WEB410 on Asynchronous Pages. New classes like PageAsyncTask help you to develop asynchronous working web pages; good code examples at http://blogs.msdn.com/dmitryr
After that CTS354 on some daily life problems that we as developers have to solve and what techniques Microsoft has to tackle them. Nice roleplay between the supposed speaker and a figurant from the audience (who turned out to be his boss).
Again the contract first instead of code first tactic was mentioned to avoid interoperability problems (use no platform specific types)
Examples of how to send attachments over webservices, reliable messaging and integration. Live demo on VS.NET built application that integrated with mainframe application (3rd party tool OnWeb of NetManage)
After lunch the long awaited ARC411 session on the Domain Specific Language tools to do model driven development in VS.2005
VS.2005 is extensible in that you can create your own grahpical designers (like the Architecture and Class Designers) to automate your development process. You define your domain model, shapes, connectors and a mapping between model and shapes. Then you just generate the designer (code) and build it. With the designer you generate artifacts like code, reports etc. This is done by adding script to parts of the model in an ASP-like language <#some code#>. This is done with the DSL tools
The team has still a TODO list:
- add model data access
- add model validation
- add UI & designer behavior
- add custom XML serialization
- add richer designer for models, notation and mapping
- add multiple views and multiple models (currently 1 view and 1 model so 1 artifact file)
- add designer deployment support
These tools are available at http://lab.msdn.microsoft.com/teamsystem/workshop/dsltools. Sure we will see more of these guys.
I skipped the 2nd keynote to do a handson lab with the DSL tools. Unluckily I got the bugs when generating the designer code so it would not build.
Finally thwe CTS449 on BizTalk 2004 and Indigo. Morten Abrahamsen and his team built a BizTalk adapter in VS.2003 that uses the Indigo programming style to do messaging. First an introduction on when to use Indigo (transport independency, extensibility) or BizTalk (brokering intermediary, orchestration). The challenge was to design the adapter in VS.2003 and the BizTalk Adapter Framework (toolkit for VS.2003) and run with the 2.0 Framework. There is a deployment issue: because it's a .NET built extension is uses a XML config file for it's setting while BizTalk stores it's configuration in SQL Server.
Heavy talk at the end of yet another long day, so a lot of people left the session be fore the end to go to the Tech-Ed party. The code is available on GotDotNet
This year I was lucky to visit Tech-Ed the full 5 days so I want to used this blog to share some of the stuff I've been to (and through...)
My preconference day track was about ASP.NET 2.0. Keywords were zero code and extensibility. The Redmond guys made things even simpler (less coding, more configuring) and extensible to suit your own needs.
Seven hours of new ASP.NET stuff in a nutshell:
- new code behind model (classes get separated into different files so you don't see the generated code anymore)
- autocompile everything (just drop files into the right solution folder)
- precompile and deploy without source
- declarative databinding (no code)
- define datasources (5 types), connect controls to them, binding of own objects made easier, 2-way binding
- datasources support caching, less server roundtrips
- enhanced controls (GridView and others)
- master pages for standard page layout
- easier security through membership service and supporting controls, extensible
- role based security out of the box, stored in SQL Server 2005 or other datastore
- easier profiling, stores per-user data persistently
- easier localization, set the (UI)Culture at the @Page directive, global and local resources in solution folders, controls support localization
- easier site navigation with TreeView, Menu, SiteMap controls and classes, XML-controlled
- easier configuration with ASP.NET WebConfigurationManager
- build health monitoring tools by catching web events
- SharePoint webpart integration in your webapplications
- advanced features like asynchronous pages, client callback manager
My first interest in computers came when the shops nearby my school started to show and sell home computers. Machines like the Sinclair ZX-80, Atari 400/600/800 and Commodore's with an amazing memory size of 4, 8 or maybe 16 KB (that's no typo). You had to use some BASIC-slang to get them doing things you wanted.
A little crowd of 'wizkidds' used their lunchbreak to show the shopping masses their latest hacks...So I went to the library to get some books on this computer programming and soon I was one of them. The sales people liked the attention we created, so most of the time we used the color / graphics capabilities of the little machines. The ideas of 'doing something with computers' was born...
When I went to college I bought my first PC. I learned the craft of writing software in Pascal and C (and some odd languages like LISP, Prolog and Simula) besides a lot of theory on datamodelling, building compilers and formal methods to prove the rightness of code.
After that, my first job was at a little company that sold hardware and developed document imaging systems. There I learned to play almost all roles in software development (because projects we mostly 1 man resourced). After 3 years of developing in Clipper, C and Pascal, I thought it was time to move on and came across this company named CMG...
There I spent my time developing more systems, again in Clipper, but soon MS-Access, SQLWindows, Visual Basic and C, and for the last years in C#/.NET with databases like SQL Server and Oracle.
Nowadays I'm a lead developer / software architect in the Microsoft Competence team of Public Sector.
My credo's in this job are: software should be maintainable (by all types of developers), should do what the customer wants and should be made within time and budget. I am a strong believer of tight user / developer interaction and early prototypes to get feedback and create acceptance for the end product and being pragmatic about things. If we want to write software in 5 or 10 years from now, we must learn to do that in the most efficient way and leave all the re-invent-the-wheel stuff to people's spare time. Therefore I'm interested in software development practices and pragmatic software architecturing.
Or to speak with my first company manager's slogan: we do the right things first and we do the things first time right.
This year at Tech-Ed, I visited the pre-conference track on ASP.NET 2.0. I 'd read already on various MSDN pages about the great improvements that our Redmond friends were up to, but I think they've done a great job here. I'm not a web-developer pur-sang (since my roots are at the WinForms application development) but the 2 keywords that stuck were: zero-code and extensibility.
Finally we can easy add navigation to our web-applications, set global page layout much easier with master pages, put some security to our applications and off we go...and a lot of this stuff is customizable with properties and designers.
With that in mind I stumbled around the Internet this weekend and came across these nice sites about web-design:
http://www.adampolselli.com and http://www.simplebits.com
They are not in any way Microsoft adepts but I liked the ideas presented, especially the colour trends and style types. So maybe my next ASP.NET project will use some of the things I found here.
PS: I've used the minitabs idea of simplebits to hack this blog's style a bit...