September 7, 2007
How To Do 2-Tier Client/Server Using NHibernateYou happen across a group of primative tribesmen in the darkest corner of Epping Forest. They are cut off from the modern world and have only the most basic tools for hunting, cooking and making clothes from the skins of the animals they kill in the forest. You want them to learn about the outside world, so you make a gift to them of a 42" widescreen HD-ready LCD TV, with Sky Digital (including film and sports channels) and teach them how to use it. Imagine your disappointment when you return 6 months later and discover that they've been using it as a coffee table.
I think I know how that might feel...
It never occured to me that you could do this, but now that I've seen it done, it strikes me that there's absolutely no reason why it couldn't happen.
You can create 2-tier client/server applications using Hibernate.
Here's how you do it:
Remember how 2-tier used to work, back in the bad old days? Basically, it worked like this: you click button A, which calls SQL stored procedure B, which returns dataset C, which we bind directly to user interface widget D. Most user interactions involve a trip to the database, and the Model-View-Controller responsibilities are split between the UI (View), stored procedures (controllers), and database tables (model).
Of course, in recent years some teams have created what I call "faux n-tier" applications which are really just 2-tier applications with an extra couple of layers added to marshall the database requests and responses between the UI and the DB server.
But the actual control logic is still mainly written in SQL (along with heaps of business logic, of course, and let's not forget how much control and business logic ends up in the UI, too.) The so-called Business Logic Layers in the Duwamish Books rip-offs actually, for the most part, don't have any real business logic in them.
While hoardes of ex-VB programmers have ably demonstrated that you can still do procedural, 2-tier programming in a proper OO language, it never crossed my mind that you cold do it using a fully-fledged object-relatonal persistence framework like NHibernate.
Until recently, that is.
To do 2-tier client-server using NHibernate is staggeringly straightforward. Now you just code it so that when the user clicks button A, it calls a "controller" B, which executes an NHibernate query Q which generates some SQL, calls the database, and lets NHibernate build a response in the form of data transfer objects that have no behaviour, or indeed, any relationships with another other types of domain object - effectively, strongly typed datasets. Nearly every user interaction requires a trip to the database and the intervening layers do little more than marshall requests and responses between the database and the UI.
How did this happen? I don't know - but I can imagine. I suspect what happened was that the architect told a team of Duwamish Disciples that they must use NHibernate on their project. They said "okey dokey, squire", and went away and built the only kind of architecture they know with it.
Posted 13 years, 9 months ago on September 7, 2007