Perhaps I should write an article
-
There is an additional cost - complexity. I can note that when I tried the solution I was generating everything so there was no actual manual requirement to create the code. I still considered it overly complex and if one doesn't generate the solution then there is an increased cost due getting it correct. In general external source mapping is not a one to one process. Thus an external client (human or otherwise) might incorrectly use an external web service in such a way that it has nothing to do with a database field. Which is why validation must occur, regardless, at the boundary level. And validation must continue to occur since one cannot rely on the client not changing. (Should note that although I don't work with client GUI I have implemented a lot of mapping APIs and that is why I always validate at the boundary layer now.)
I see your point. I tend to keep service layers as thin as possible. They deal only with exposing an interface to the underlying application logic and whatever security may be required. Data is only passed on in both directions. A little like a post office where they are mostly concerned with receiving and delivering packages, but not very much with what's inside the packages. The first thing that must happen in the logic layer, of course, is a a complete validation. But that's exactly why I moved the validation into the data object. Any layer can then perform a complete validation of any data object at any time. There are no redundant implementations of this validation code and everything is set up in just one method, usually the constructor of the data object.
-
Paul, I have begun programming long ago on a small computer I built from a kit with 4k RAM and great 32 x 64 pixel monochrome graphics. And the programs were machine code, entered diectly with the hexadecimal keyboard. And I still do that today, since I still have the old computer. I think that things can't get any more spartan or awkward than beginning with an absolutely empty memory and writing the first instructions which are to be executed after the CPU's reset. That's one of my first idea was to put every little fragment of code into some kind of library. The 'library' was a cassette tape on which I had saved all kinds of routines and a sheet of paper where I had written down what routine was to be found at which position on the tape. 'Linking' was done by loading the routines to the desired memory location and adapting the branching instructions manually. Here[^] you have a recreation of my little 'library'. I did it in two boring days before christmas, using an assembler and an emulator on my notebook. Pure luxury, just like using the memory wasting 64 x 64 resolution. :) I have been writing libraries for and against everything ever since. At first that may be slow, but over time you have so much useful and working code that you can do great things very quickly. It has always been like Lego, with the difference that I made more of my own pieces than buying boring sets off the shelf. And, if I have the choice, I prefer to spend my time crafting some new parts to the best of my ability than trying to read up on the next great thing a company wants to sell me and struggling to adapt my code just in time for the next big change. Or perhaps I just enjoy being a blak sheep that refuses to run along with the rest of herd :)
That, sir, is really cool :cool: Also your Lego metaphor is completely right and puts everything to the point: building blocks of software that match each other like Lego blocks is of course always possible, but there are platforms which make things easy and others make things hard... Cheers, Paul