If anything "sets you up for failure in so many ways", it's replacing analysis of your project with some "thou shalt not" rules you picked up in a magazine somewhere.
Everyone knows the sign of a debater who is confident in his argument is a parting insult... I've done software design for over a decade. I didn't pick this stuff up from a magazine.
When you scale an application by adding "application servers", you re-test all the software on that server before making it live. The same thing is done for upgrades. You take it out of the Virtual IP or Broker or whatever (based on the technology) and you retest that server.
When you upgrade your database, the whole system has to be taken down in order to do so. Of course, you should create an entirely new database on the new DBMS version and then port the data and then regression test, but the system goes down during the switchover. It's a higher impact.
I'm certainly not against modularization, that just wasn't the original poster's question.
Actually, the post is called "where does the business logic belong?". I'm not off-topic by any measurement.
If I have 100 applications (or 10) doing the same thing to my data, of course I want all the applications to use the same bit of code. Whether that code is a stored procedure or a Web service or whatever is an implementation detail that depends on tradeoffs particular to the application and development environment (and "ease of testing" should certainly be involved in this decision). "Business logic" isn't a precise enough term to justify any kind of hard-and-fast rule stating "where it belongs".
I agree with what you're saying here, but I believe very strongly that, unless it is special circumstances (small app, extremely tight schedule), the business logic (algorithms, business rules, etc.) should always be separated from the database. It provides more flexibility and better scalability, which, nowadays are very important.
There are also important architecture discussions to be made in terms of application layering within these tiers which would greatly assist in scalability and modularity.
My rule of thumb is that the default focus should be long-term and extremely robust and that people need to convince me that this software will not need that kind of attention. Most places completely under-estimate the life cycle of their software.
I won't cause problems for a company. If their restrictions require that things be done in a 2 (physical) tiered manner, then it can be done that way, I will just warn them of the problems this will cause them when they start expanding their user base and their code base.
Well, I don't think that the Tooth Fairy really approves of what the Easter Bunny's doing. Feeding all that chocolate to kids is causing all the teeth to rot. Some even are taken by dentists around the world!
Rotten teeth are too weak to be part of the Tooth Fairy's Dental Castle of Fortitude. If she doesn't get strong teeth for her Castle, her plans for World Domination will fail!
Actually, I heard a rumo(u)r that she took a hit out on the EB...
Why is it that nobody seems to pay attention to the fact that an upgrade to a piece of software can be as bad as switching vendors??
It's not like a company is never going to upgrade their databases! Once an upgrade happens, the underlying code has changed... This requires you to retest your application.
Would you rather retest reading data from a table and making sure it hasn't translated into Swahili or retesting all the complicated Business Logic of your application?
Upgrading software is just as bad as changing vendors. Obviously, the compatibility will be much higher within one vendor's products, but when you change versions of anything (Compiler, RDBMS, WebServer, OS), you have to restest everything! Some places don't do this for patches and such (to their great detriment for that 0.1% of the time when they get f*cked).
Eventually, an upgrade will break your software. So, portability is a concern even if you're CIO is blowing Larry Ellison in his spare time. Different versions of _any_ software can have incompatibilites. Some times patches fix a bug whose side effects your software was counting on. It's a fact.
Portability is not just a cross-vendor or cross-platform concept. It is also a time-based concept within a single vendor.
You obviously have no friggin idea what good software is. MSFT wasn't the inventor of this architecture. It is a very old concept that was simplified (some would say not so well by COM and I agree...)
Putting everything in the database sets you up for failure in so many ways... First of all, what happens when the DB Server needs to be upgraded???? YOU NEED TO REGRESSION TEST EVERY SINGLE APPLICATION IN YOUR CORPORATION!!!! That's ridiculous!!
You should have Unit tests for each layer in your software... You just fire of JUnit, NUnit, whatever on your DATA Layer and wait for the results. No need to retest the Business Logic at all..
By having separate pieces, you control and minimize risk in the software as things change.
Putting everything in the database is a narrow-minded simplistic approach that, however, is very appropriate for certain, smaller or short-life-cycle applications.
Why is it that every person on here who jumps up and down and says "DATABASE!!! DATABASE!!!! YOU MUST!!!" just _happens_ to be a DBA?? Hmm...
Well, I do Software Architecture/Design and implementation for a living (12 years experience) and I would say you have to do it in the Application/Business/Middle Tier(s) because middle tiers can be distributed and scaled much easier than databases. I would use Stored Procs and Views for certain things, but only to join tables and massage the data, I would _NOT_ put logic there that has system-wide implications...
Testing a Business layer component can be done independently of the database and swapping out a component on a single machine can be tested on the same database schema (even in production in many situations) without locking the system down.
Fixing bugs in the Business Layer does not require taking down the system, which is required for changing stored proc-based logic.
And, of course, never mind buying that ridiculously powerful machine to run all those queries on ONE box or a cluster of Crazy boxes when you can just have TONS of smaller machines do the work for you.
...pick a nice, random seven-char password, and make one consistant character (say, the third) something as simple as the first letter of the machine/site using that password. Perhaps not suitable for really highly sensitive information, but a hell of a lot better
(and easier to remember, in most cases) than "my dog's name" or "my kid's birthday".
May I suggest that if you can remember a random 7 character string with another algorithm to insert another character better than your dog's name or your child's birthday, that you seriously reconsider pet ownership or rearing children...
Well, as far as I am concerned, the setting should be in BOTH places
How does that solve the problem of having everything cluttered with options? Frankly, I _hate KDE's control center
It doesn't. But, removing the setting completely replaces one problem with another.
I'd rather have an advanced option (and I think it is very debatable that this is an advanced option) on an "Advanced" Tab in a settings dialog. Otherwise, the n00b has to divine that there's some _other_ application out there that changes settings for _this_ one.
And, as far as the gnome mailing lists... A new users is obviously not going to see that either. So, the existence of gconf-edit is a mystery. One should _always_ be able to get to all the settings for an app from inside the app. At _least_ put a button that launches gconf-edit from the configuration dialog or something to that effect.
Well, as far as I am concerned, the setting should be in BOTH places. The app could pop up a warning saying "this is a global setting and will affect all other GNOME apps. Are you sure you want to do this?". Or, even more friendly : "Do you want this setting to pertain just to this application or to all GNOME applications?".
As you said, "the advanced user has no prob finding them". That's the problem. How are people supposed to adopt the OS when a setting as simple as this is only easy to find for "advanced users"?
I think it's stretching it a bit to call it a lie... the fact that there's a difference between "browsing" files and "managing" (?) files is something I only learned today.
It pissed me off to try to find a file and wind up with an assload of open windows. I said to myself "MAN! I need to find that setting NOW!". And, being somewhat of a n00b on Linux lately, I couldn't find the friggin setting!
So, having to launch a _separate_ program to change the setting is basically equivalent to running the Registry Editor in Windows as far as many people are concerned.
The configuration for how a thing behaves should be changeable on THAT thing, not somewhere else. It's just basic usability!
First, I'm not sure I agree with his statement that having folders open in the same window is the better way to do things. If I'm moving or copying a file from one folder to its parent, having two windows open is more efficient for me. It's easier for me to just drag the file between two open windows than to highlight the file, say Cut, then move up a level and say Paste.
So... you spend all your time copying files between parent and child folders? This type of activity is the exception rather than the norm in users' use of a file browser... The user is normally searching for a file... clicking through many subdirectories gets you an assload of windows on the screen before you get to your file.
WhoTF wants that? And, somehow, it's supposed to be obvious to fire up a separate app to change this setting?
Just go into the registry... (hehe... I know.. he was bitching about the registry)... But, seriously, if you want Tab completion to work in your regular Windows command prompts, change the HKLM\Software\Microsoft\CommandProcessor\Completio nChar to 9 (TAB in ASCII).
Then, you can tab complete (it will actually TAB complete the whole word, and you can cycle through words beginning with the characters typed by continuously hitting TAB.).
I'm not sure if it's on the box, but when you put them in a DVD-ROM drive, you can see how much space it takes up. If it's less than 4.7GB, it's gotta be a single-sided, single-layer disk.
If you see more than 4.7, it's going to be a single-sided (cause you haven't flipped it!), double-layer which is 8.5GB,
If you see 4.7 on one side, then you flip the disk and see another 4.7, it's a 9.4...
Some movies you buy have the widescreen movie on one side and the 4:3 ratio on the other. These are usually 9.4 disks. In order to read them on a PC, you'd have to manually flip them. (Think 5 1/2" floppies before double-sided drives)
Slashdot Mirror
Mommy! Georgie won'w play nice! He won't do things EXACTLY AS I WANT THEM!! *sniff* *sniff* WAAAAH!!!
Get a grip!
If anything "sets you up for failure in so many ways", it's replacing analysis of your project with some "thou shalt not" rules you picked up in a magazine somewhere.
Everyone knows the sign of a debater who is confident in his argument is a parting insult... I've done software design for over a decade. I didn't pick this stuff up from a magazine.
When you scale an application by adding "application servers", you re-test all the software on that server before making it live. The same thing is done for upgrades. You take it out of the Virtual IP or Broker or whatever (based on the technology) and you retest that server.
When you upgrade your database, the whole system has to be taken down in order to do so. Of course, you should create an entirely new database on the new DBMS version and then port the data and then regression test, but the system goes down during the switchover. It's a higher impact.
I'm certainly not against modularization, that just wasn't the original poster's question.
Actually, the post is called "where does the business logic belong?". I'm not off-topic by any measurement.
If I have 100 applications (or 10) doing the same thing to my data, of course I want all the applications to use the same bit of code. Whether that code is a stored procedure or a Web service or whatever is an implementation detail that depends on tradeoffs particular to the application and development environment (and "ease of testing" should certainly be involved in this decision). "Business logic" isn't a precise enough term to justify any kind of hard-and-fast rule stating "where it belongs".
I agree with what you're saying here, but I believe very strongly that, unless it is special circumstances (small app, extremely tight schedule), the business logic (algorithms, business rules, etc.) should always be separated from the database. It provides more flexibility and better scalability, which, nowadays are very important.
There are also important architecture discussions to be made in terms of application layering within these tiers which would greatly assist in scalability and modularity.
My rule of thumb is that the default focus should be long-term and extremely robust and that people need to convince me that this software will not need that kind of attention. Most places completely under-estimate the life cycle of their software.
I won't cause problems for a company. If their restrictions require that things be done in a 2 (physical) tiered manner, then it can be done that way, I will just warn them of the problems this will cause them when they start expanding their user base and their code base.
T
What's a VCR?
Santa: "Tuuux... I am your father!"
Tux: "NOOOOOOOOOO!"
(*They proceed to have a sword battle using large candy canes...*)
Well, I don't think that the Tooth Fairy really approves of what the Easter Bunny's doing. Feeding all that chocolate to kids is causing all the teeth to rot. Some even are taken by dentists around the world!
Rotten teeth are too weak to be part of the Tooth Fairy's Dental Castle of Fortitude. If she doesn't get strong teeth for her Castle, her plans for World Domination will fail!
Actually, I heard a rumo(u)r that she took a hit out on the EB...
Well, maybe the creative spelling is interesting ... :)
Why is it that nobody seems to pay attention to the fact that an upgrade to a piece of software can be as bad as switching vendors??
It's not like a company is never going to upgrade their databases! Once an upgrade happens, the underlying code has changed... This requires you to retest your application.
Would you rather retest reading data from a table and making sure it hasn't translated into Swahili or retesting all the complicated Business Logic of your application?
I prefer the former...
Upgrading software is just as bad as changing vendors. Obviously, the compatibility will be much higher within one vendor's products, but when you change versions of anything (Compiler, RDBMS, WebServer, OS), you have to restest everything! Some places don't do this for patches and such (to their great detriment for that 0.1% of the time when they get f*cked).
Eventually, an upgrade will break your software. So, portability is a concern even if you're CIO is blowing Larry Ellison in his spare time. Different versions of _any_ software can have incompatibilites. Some times patches fix a bug whose side effects your software was counting on. It's a fact.
Portability is not just a cross-vendor or cross-platform concept. It is also a time-based concept within a single vendor.
Huh? What does this have to do with where the Business Logic lies in a large software app??
I hate responding to ACs, but...
You obviously have no friggin idea what good software is. MSFT wasn't the inventor of this architecture. It is a very old concept that was simplified (some would say not so well by COM and I agree...)
Putting everything in the database sets you up for failure in so many ways... First of all, what happens when the DB Server needs to be upgraded???? YOU NEED TO REGRESSION TEST EVERY SINGLE APPLICATION IN YOUR CORPORATION!!!! That's ridiculous!!
You should have Unit tests for each layer in your software... You just fire of JUnit, NUnit, whatever on your DATA Layer and wait for the results. No need to retest the Business Logic at all..
By having separate pieces, you control and minimize risk in the software as things change.
Putting everything in the database is a narrow-minded simplistic approach that, however, is very appropriate for certain, smaller or short-life-cycle applications.
Why is it that every person on here who jumps up and down and says "DATABASE!!! DATABASE!!!! YOU MUST!!!" just _happens_ to be a DBA?? Hmm...
Well, I do Software Architecture/Design and implementation for a living (12 years experience) and I would say you have to do it in the Application/Business/Middle Tier(s) because middle tiers can be distributed and scaled much easier than databases. I would use Stored Procs and Views for certain things, but only to join tables and massage the data, I would _NOT_ put logic there that has system-wide implications...
Testing a Business layer component can be done independently of the database and swapping out a component on a single machine can be tested on the same database schema (even in production in many situations) without locking the system down.
Fixing bugs in the Business Layer does not require taking down the system, which is required for changing stored proc-based logic.
And, of course, never mind buying that ridiculously powerful machine to run all those queries on ONE box or a cluster of Crazy boxes when you can just have TONS of smaller machines do the work for you.
I'm holding out for the Winnebago! :)
If you read the article, that's the mileage it gets _on_the_ground_... not in the air!
Heck, it probably ways less than many SUVs too! Probably has no towing capacity and is extremely streamlined...
More appropriately (because of its shape), it should be compared with sporty cars and, there, it's not so great..
May I suggest that if you can remember a random 7 character string with another algorithm to insert another character better than your dog's name or your child's birthday, that you seriously reconsider pet ownership or rearing children...
It doesn't. But, removing the setting completely replaces one problem with another.
I'd rather have an advanced option (and I think it is very debatable that this is an advanced option) on an "Advanced" Tab in a settings dialog. Otherwise, the n00b has to divine that there's some _other_ application out there that changes settings for _this_ one.
And, as far as the gnome mailing lists... A new users is obviously not going to see that either. So, the existence of gconf-edit is a mystery. One should _always_ be able to get to all the settings for an app from inside the app. At _least_ put a button that launches gconf-edit from the configuration dialog or something to that effect.
Hey... no need to refactor. It's better to be verbose than to skimp on the details. I was just joking anyway.
Thanks for the interview!
Is everyone in your country so verbose??
Man... He was writing novels for answers there!
Good stuff though. Interesting.
Well, as far as I am concerned, the setting should be in BOTH places. The app could pop up a warning saying "this is a global setting and will affect all other GNOME apps. Are you sure you want to do this?". Or, even more friendly : "Do you want this setting to pertain just to this application or to all GNOME applications?".
As you said, "the advanced user has no prob finding them". That's the problem. How are people supposed to adopt the OS when a setting as simple as this is only easy to find for "advanced users"?
T
I think it's stretching it a bit to call it a lie... the fact that there's a difference between "browsing" files and "managing" (?) files is something I only learned today.
It pissed me off to try to find a file and wind up with an assload of open windows. I said to myself "MAN! I need to find that setting NOW!". And, being somewhat of a n00b on Linux lately, I couldn't find the friggin setting!
So, having to launch a _separate_ program to change the setting is basically equivalent to running the Registry Editor in Windows as far as many people are concerned.
The configuration for how a thing behaves should be changeable on THAT thing, not somewhere else. It's just basic usability!
So... you spend all your time copying files between parent and child folders? This type of activity is the exception rather than the norm in users' use of a file browser... The user is normally searching for a file... clicking through many subdirectories gets you an assload of windows on the screen before you get to your file.
WhoTF wants that?
And, somehow, it's supposed to be obvious to fire up a separate app to change this setting?
That's ass.
Just go into the registry... (hehe... I know.. he was bitching about the registry)... But, seriously, if you want Tab completion to work in your regular Windows command prompts, change the HKLM\Software\Microsoft\CommandProcessor\Completio nChar to 9 (TAB in ASCII).
:)
Then, you can tab complete (it will actually TAB complete the whole word, and you can cycle through words beginning with the characters typed by continuously hitting TAB.).
Ahhhh... much better
I'm not sure if it's on the box, but when you put them in a DVD-ROM drive, you can see how much space it takes up. If it's less than 4.7GB, it's gotta be a single-sided, single-layer disk.
...
If you see more than 4.7, it's going to be a single-sided (cause you haven't flipped it!), double-layer which is 8.5GB,
If you see 4.7 on one side, then you flip the disk and see another 4.7, it's a 9.4
Some movies you buy have the widescreen movie on one side and the 4:3 ratio on the other. These are usually 9.4 disks. In order to read them on a PC, you'd have to manually flip them. (Think 5 1/2" floppies before double-sided drives)
Make sense?
Make sure you're right before you start flinging stones, glass houses boy.
:)
too bad there isn't a "-1: Wrong" moderation option
A $2000 tax break is not equal to $2000.
If your tax rate is 30% (it may be lower), it is equal to $2000 * 30% = $600.
So, your car cost $18,400 ($1400 more - after deduction).
T
Maybe he's the "Bizzaro" Albert Einstein.
He thinks that the world is flat and that space is separate from time and that time is linear.
He once saw some Emcee at a club... he said "he is so good... he's Emcee Squared! W00t!"