Virtually every architect has wrestled with problem of where to put ‘Business Logic’ and as technology changes and matures I doubt there will ever be a correct answer.  The rules stating that ‘business logic’ should always go here or there are stated by people who would only be able to depict application architecture with a set of crayons and a colouring-in book.   I have seen applications where none of the 'business logic' is in the database and a whole lot of wrapper classes do everything that a database would do (such as enforce foreign key constraints) - to the other extreme where virtually the entire application is developed in the database.  As with everything in software architecture, you need to weigh the pros and cons that are specific to your application.  So some pointers:

• Define what you mean by 'Business Logic' - this means many different things to different people and it is a good idea to establish some sort of baseline.  One could argue that tables in the database, by virtue of the fact that they represent business semantics, are in fact business logic.  Generally 'Business Logic' refers to some sort of procedural programming, but you would be well advised to define, agree and document what functions your business logic performs.  You will probably find that 'business logic' spans all layers and technologies - you have to understand what type of business logic goes where.
• RDBMS's do perform some 'business logic' incredibly fast and it would be pointless to try and 'roll your own' mechanism in another layer.  Things that are best left to the database include enforcing referential integrity, ensuring primary keys are unique etc.
• Most native database languages (by this I refer to PL/SQL & T-SQL - not Java or .NET in the database) execute extremely fast and almost always faster than an external language.  There are some cases that you can see a performance benefit in external applications, but this is usually for bulk operations where plenty memory is available - where you can suck lots of data out, work with it in memory and dump records into the database in one go.  As a .NET or Java developer, you will almost always lose an argument if performance is an issue.
• Database vendors are trying to turn their databases into application servers and referring to 'the Oracle database' actually refers to more than just the RDBMS.  SQL2005 has a 'Database Engine' (the RDBMS) as well as 'Reporting Services', 'Integration Services' etc. which, although bundled with the database are not really part of the RDBMS.  So when assessing the 'extended' functionality that is offered such as providing 'Business Object Services' out of the database, think carefully that this is not the core of the database and the suitability of the database platform for providing the architectural framework needs to be assessed as if it was any other (non-database) technology.  My favourite example is a database 'feature' of being able to send email from within database stored procedures; not RDBMS functionality at all!  Obviously database vendors want to sell more product and create tie-in to their platform, particularly Oracle who uses the well establish RDBMS brand to punt the rest of their products - be wary of database vendor marketing material.
• On the newer database platforms you can run Java or .NET code that is executed by the database.  This is useful in some cases but mostly it is unnecessary because the native languages a frikkin' fast by comparison as the engine has been coded up over the years with them in mind, and the set-based paradigm that we are used to in database languages doesn't translate all that well with more object oriented constructs.  Mostly you would use this for accessing some external functionality.  Also, the database has less control over these types of applications and badly coded .NET or Java on the database server can bring it to its knees.  In SQL2005 the CLR actually runs inside the SQL memory space and processes and is managed by the database engine - allowing the database itself to prioritise, allocate memory or even kill rogue tasks in order to satisfy the real RDBMS operations that are being performed.  I know that Oracle9i spawned off JVM's that were in control of the OS, not the database - I don't know if this has changed in 10g.
• Lastly - make sure that you are consistent in where you put business logic.  Often the biggest problem is that in one module a type of business logic is in one place and in and in another module it is elsewhere making it difficult to maintain, debug and migrate.  Wherever you decide to put the business logic (or parts of it), make sure that it is consistent across the project.

This question has been around for a long time and will there will never be an answer that applies across the board.  Like everything in systems architecture, you have to look at the specifics of your project to come up with the best approach.

Simon Munro

Last months' announcement by the Borland CEO that they are getting out of the IDE business makes one of the loudest statements about Delphi in a long time.  Depending on who you speak to it is the final nail in the coffin, a interesting footnote on an already dead product, or to the minority - a good thing for Delphi.  Whatever you think it means, I doubt that Delphi will ever return to it's 90's glory days.

A more relevant question than 'What happened to Delphi?' is: 'Why is www.delphi.co.za hosting a blog where an individual is going on about non-Delphi stuff?'

So let me try and answer that question.

I used Delphi from v1 to v7 (the last 'good' Delphi) and built much of my professional career on Delphi.  Mark Shuttleworth, who because of the gazillions of dollars (pounds or whatever) he has, can advocate the use of open source as much as he likes - he never has to work again.  I could be an all out Delphi developer; but for commercial reasons it is just not possible - I just don't have the kind of cash the Mark Shuttleworth does.  While Delphi may be used in some niche markets, in the area they I work in - data-centric business applications - if you are not developing in .NET or Java it is virtually impossible to find regular work at a reasonable income.

It becomes particularly difficult when working at the architectural level.  For some reason people belive that Delphi is a non-Microsoft platform, when Delphi actually has always been at the bleeding edge of Microsoft technology.  I remember developing apps that ran on SQL Server 4.21 on Windows NT 3.1 (on a 486DX266!).  In 1995, on a Borland roadshow, I demonstrated Delphi creating ActiveX controls - the only other tool at the time was VC++ (I think VB was still in version 4).  It was also around that time that the first data-aware TreeViews became available - something that development tools are still struggling with.  I was on a team where we wrote complex multi-tier applications with DCOM at the height of that fashion. On the web I used Delphi to create super-fast ISAPI DLL's before ASP was even on the market.  Delphi was the Microsoft development tool of choice for those who didn't have the patience for MFC and couldn't stand the data-crippled flicker-infested applications that came from VB.  For some reason though, Delphi (and it's cousin C++ Builder) were soldiers in a non-existent battle of Windows compilers - when the real battle was for the server platform where .NET, Java and others were striking blows.

Most of the good Delphi developers that I have worked with have found a home in .NET - it is commercially viable and has some nuances of the VCL that have probably seeped through from Anders Helsberg - the original Delphi architect and now the creator of C#.  I, like many of those developers still use Delphi often - although we seldom admit it to others.  I still have a fully functional Delphi environment with all the Developer Express components and can snap together a data-aware application faster than any other tool.

Delphi still has a place in the market and many good tools out there use Delphi.  The Skype windows client is developed in Delphi and so are TOAD and PL/SQL Developer - the essential tools in any Oracle developers toolbox.  Delphi was a leader in development architecture - Windows functionality (as mentioned above); the best tool for data-aware applications; the only tool with decent grid controls thanks to Developer Express; one of the first to practically implement the concept of a disconnected data set (TClientDataSet); quick off the mark with DCOM and Web Services; implementation of the concept of a data source (1993) - something .NET is only now getting around to.  The list goes on and every Delphi developer will be able to list their favourites.

Delphi succeeded despite Borland's pathetic marketing - the tool was so superior that the developer community simply used it; not because it was well marketed.  Delphi even survived the Inprise debacle but was, already then, becoming sidelined.  Borland then decided that the future of Delphi was .NET, which is really just Pascal for .NET  - yet another obsure language that supports the platform.  Whoever made that decision forgot that Delphi's strengh was always the compiler and the VCL - by going the .NET route you lose both; leaving behind an outdated IDE... which is now being dumped.

Delphi will still have a place in my personal toolbox and will always be remembered as a platform that I enjoyed developing on and had great success with.  However, my migration to .NET was not the Delphi route and I see no future for Delphi on the Windows platform as the outdated compiler fails to support Windows Vista.

The announcement has no effect on me professionally or commercially... it only has an emotional effect as I am forced to read the writing that has been on the wall for a while.

Simon Munro

Welcome to delphi.co.za

As with many websites, the lack of meaningful content within an existing structure results in a website that stagnates to a point that even the owner loses interest.

I am undertaking this blog as a challenge to produce some worthwhile content in the areas that I work and think in.  Hopefully, soon this blog entry will slide down the page into the archives.

Simon Munro