Application logic and Business logic
Vijay Singh
describing the "Data Transfer Object" pattern, the author said that
application logic and business logic should be kept separate from each other
i,e should be decoupled. I was wondering if anybody can make out what he
means. Whats the difference between application logic and business logic?
Thanks
Vijay
topmind
costs are higher than the benefits on average. I would say don't worry
about it, but you may have to work in a shop that follows this silly,
code-bloating practice and therefore may need to understand the
(flawed) dogma.
(Note that rejecting this dogma does not imply I promote
copy-and-paste. Factor out commonalities based on need, not dogma.)
Robert C. Martin
Business logic is rules associated with the business. Application
logic is logic associated with the particular features of the
application. For example, a business rule is
Salary = hourlyRate*hours
An application rule is:
pulldownList = sortedListOfEmployees.
The business rule has meaning to the business. The application rule
has meaning to the user of the tool, but not to the business.
-----
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
Patrick May
[ Question on the difference between application logic and business
logic. ]
> Personally I think the whole "separation" thing is horse crap. The
> costs are higher than the benefits on average.
That's an interesting assertion. What evidence do you have to
support it?
Sincerely,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
p...@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)
Darius Zakrzewski
Business logic is also referred to as domain logic.
Application and domain logic are present in every application, but not all
projects choose to make that separation. If a separation is not being made,
the code for the application and domain logic is intertwined.
Application logic usually resides in its own layer on top of the domain
layer. Therefore, the usual benefits and drawbacks of the Layering Principle
(as outlined in the “Pattern-Oriented Software Architecture” by Frank
Buschmann et al;) apply here, the thinking being similar to two- and three
tier applications (ignoring the aspect of physical deployment).
The larger and more complex the application becomes, the more benefits are
likely to be gained from separating application and domain logic, e.g. like
the seven (7) layers of the OSI model.
Darius Z.
"Vijay Singh" <vij_...@hotmail.com> wrote in message
news:XnrTd.140772$68.3...@fe1.news.blueyonder.co.uk...
H. S. Lahman
I can't speak for the EJB context, but to me business logic refers to
rules and policies of the problem domain that are abstracted for the
subject matter solution. Thus for accounting software the rules of
double entry bookkeeping and standard accounting practices would be
abstracted in the business logic.
In contrast, application logic would be the rules and policies that
represent various aspects of the computing space. They are dictated by
things like the technologies used or computational models. Thus an
event queue implements the rules and policies of asynchronous message
passing in a distributed context and an RDB represents a particular
suite of rules and policies for persistence. IOW, application logic
refers to the way the business solution is implemented in a particular
computing environment.
Another way to think about this is in terms of functional vs.
nonfunctional requirements. The functional requirements describe What
the software should do and they are defined in terms of the business
domain's rules and policies. Nonfunctional requirements relate to How
the software executes (performance, size, security, etc.). Typically
application logic exists to resolve nonfunctional requirements within
the context of a particular computing environment.
Obviously the functional vs. nonfunctional views cannot be completely
separated in detail. However, one can go a long way towards separation
with modern techniques for modularization. For example, that's why RAD
environments tend to employ a layered model where persistence and
display are isolated in layers and exotic interface infrastructures are
used to decouple them across layer boundaries.
[One can also make a <very tenuous> analogy to OOA/D. In an OOA model
one only has objects abstracted from the business space and they only
encapsulate business rules and policies. However, in an OOD model one
adds a bunch of other objects (e.g., caches, queues, collections
classes, etc.) that address particular nonfunctional requirements and
implementation technologies. Since objects encapsulate behaviors and
have decoupling interfaces, the separation of OOA and OOD objects can be
viewed as separating business and application logic.]
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH
ale...@medcentral.com.au
The other guys have answered the difference question well enough so I
won't eloborate.
Why separate them? EJB's are available to many different applications,
therefore mixing in one particular app's logic into the business logic
layer is not appropriate for all the other apps that function
differently.
In an n-tier environment, application specific logic needs to be more
closely tied to each particular application. For that reason you would
keep the business and app logic separate.
That said, I agree with topmind, endless useless separation creates
code that may not even be required or wanted by the customer, bloat.
You need to draw the line somehow and somewhere. Do I separate business
and app logic, no. I'll do it when the customer requires (and pays for)
it.
Cheers,
Alex.
mikharaki...@yahoo.com
Perhaps, but what are the definitions?
Business logic -- the code that I would write in a high abstraction
language. Unfortunately, the languages available today are low level.
Therefore:
Application logic -- all this crappy low level code that I have to
write in order to implement the business logic.
Writing a lot of low level code contradicts the fundamental principle
of high maintenance programming: "The more code I write, the more
likely it would break". Hence the attempt to structure the code in a
such a way, that you still have a lot of code, but think that it is
more secured.
Vijay Singh
Vijay
"Vijay Singh" <vij_...@hotmail.com> wrote in message
news:XnrTd.140772$68.3...@fe1.news.blueyonder.co.uk...
topmind
support it? *)
"Decision math". The chances of switching to a different GUI or DB
vendor is relatively small compared to the cost of the extra separation
layers in terms of coding and maintenence. Add in the "future
discounting" from finance principles, and the the total weighs in favor
of not doing it.
Further, even if you do separate, often the feature set and philosophy
of new gui's is so different that you have to overhaul a bunch of stuff
anyhow.
Some justify it by saying that certain changes can all be done in one
spot, but they rarely consider the costs of changes that do not favor
that grouping. No grouping favors every change pattern. One has to
weigh the estimated probabilities of changes.
What is your justification for the wrapping? Wrapping is not the
default, so the burden of evidence is not really on me, BTW.
-T-
topmind
Dude, career-ending move. Being right is not the same as being liked
:-)
-T-
Patrick May
> > That's an interesting assertion. What evidence do you have to
> > support it?
>
> vendor is relatively small compared to the cost of the extra
> separation layers in terms of coding and maintenence.
The issue isn't GUIs or databases, it's the separation of
application logic and business logic. Business logic, in this
context, refers to the entities, rules, procedures, and processes that
represent and define the core functionality of the business. Concepts
like purchase orders, customers, service provisioning, and billing
fall into this category.
Application logic, on the other hand, relates to the way in which
those business concepts are represented to users of an IT system.
This category includes details like GUI features, report formats, and
configurations to support non-functional requirements.
These two types of logic change for different reasons, on
different time scales. In any large system, unnecessary change must
be minimized. Separating these types of logic is just plain good
engineering practice.
> Further, even if you do separate, often the feature set and
> philosophy of new gui's is so different that you have to overhaul a
> bunch of stuff anyhow.
Again, this has nothing to do with GUIs per se.
> What is your justification for the wrapping?
This isn't about wrapping, it's about decoupling aspects of a
system that change for different reasons.
> Wrapping is not the default, so the burden of evidence is not really
> on me, BTW.
The burden of proof is on the one making the assertion, as
always. If you can't back up what you want to say, you shouldn't be
saying it in this forum.
Thomas Gagne
topmind wrote:
> (* That's an interesting assertion. What evidence do you have to
> support it? *)
>
> "Decision math". The chances of switching to a different GUI or DB
> vendor is relatively small compared to the cost of the extra separation
> layers in terms of coding and maintenence. Add in the "future
> discounting" from finance principles, and the the total weighs in favor
> of not doing it.
I might regret this...
The GUI or DB may not disappear. But put yourself back in the early 90s
before the web was revealed to the unwashed masses. How great it was for
those of us with separated logic to easily and quickly front-end our systems
with HTML.
Later in the 90s and early 00s XML was revealed to the masses. How great it
was for those of us with separated logic to easily and quickly front-end our
systems with XML xactions and eventually web services.
All these great new markets, functionality, and interoperability with nary a
modification to the expensive code.
More simply, imagine you're a bank (or a firetruck) accustomed to doing
transactions for tellers on dumb terminals. Over the course of a few years
you need to handle PCs, windowing interfaces, new ATM networks, POS networks,
and your own private ATM networks.
Would you rather your business logic be wrapped-up inside the dumb-terminal
code or that it be separated into its own layer?
As far as databases are concerned it may not be that I'll change from Oracle
to Sybase, or SQL Server to DB2, but more likely that we'll need to reorganize
the database, move some fields, split some tables up, etc., and for the
business layer to have hardwired itself to a specific table layout is nearly
as restrictive as mixing business and UI logic.
Better to treat the database as a huge object that hides its data (table,
rows, fields, organization, syntax, etc.) behind methods (stored procedures)
which are the only way to transact with it.
topmind
those business concepts are represented to users of an IT system.
This category includes details like GUI features, report formats, and
Sounds like UI to me. And, what is "non-functional".
(* These two types of logic change for different reasons *)
No, sometimes they change for related reasons, and sometimes they
change for unrealated reasons. I have been observing app changes for
more than a decade. Change comes in all kinds of directions and shapes.
(* In any large system, unnecessary change must
be minimized. *)
Yes, and that is why code grouping requires a cost-benefit-probability
analysis.
(* Separating these types of logic is just plain good
engineering practice. *)
There is no impericle evidence saying that is the best choice. I see
far more matra than I do careful risk analysis.
(* The burden of proof is on the one making the assertion *)
You guys asserted it should be separated. So.....
-T-
topmind
90s
before the web was revealed to the unwashed masses. How great it was
for
those of us with separated logic to easily and quickly front-end our
systems
The problem is not because it wasn't wrapped or separated, but because
HTML and HTTP put *restraints* on UI flow that client/server systems
didn't face. It is like writing output for a color printer, and then 5
years later you get a black-and-white one instead. Either you live with
less options for 5 years, or you live with all the rich options your
current system provides and worry about what-ifs later. And, this is
assuming you could have predicted the loss of features. This is not
merely a change of implementation, but a change in fundimental UI
philosophy.
Besides, if it was a matter of plug-and-play swapping, then why not
just write the client/server API's to do HTML instead? Many c/s systems
talked thru API's rather than raw system calls, so just re-implement
them for web. Why not? Because HTML is too limited to handle c/s API's.
(* As far as databases are concerned it may not be that I'll change
from Oracle
to Sybase, or SQL Server to DB2, but more likely that we'll need to
reorganize
the database, move some fields, split some tables up, etc., and for the
business layer to have hardwired itself to a specific table layout is
nearly
as restrictive as mixing business and UI logic. *)
I will agree that for THAT particular change, grouping all the SQL
together would make it simpler. However, when dealing with
task-specific changes it makes some things harder because you have to
change BOTH the interface and the implementation. Thus, you have 2
places to change where you would only have one if there was no
separation. Separation creats a mini-buerocracy.
I've had this debate a jillion times. Indirection is NOT free. Spend it
wisely, not out of mantra.
(* Better to treat the database as a huge object... *)
Yeah, OO zealots want to tree *everything* as a "huge object". No news
there.
Alfredo Novoa
> The issue isn't GUIs or databases, it's the separation of
>application logic and business logic. Business logic, in this
>context, refers to the entities, rules, procedures, and processes that
>represent and define the core functionality of the business. Concepts
>like purchase orders, customers, service provisioning, and billing
>fall into this category.
>
> Application logic, on the other hand, relates to the way in which
>those business concepts are represented to users of an IT system.
>This category includes details like GUI features, report formats, and
>configurations to support non-functional requirements.
Agreed.
Using less words: business logic are database constraint and
derivation rules. Application logic is presentation logic.
> These two types of logic change for different reasons, on
>different time scales. In any large system, unnecessary change must
>be minimized. Separating these types of logic is just plain good
>engineering practice.
It is an essential practice, but unfortunately OOA/D does not separe
these types of logic and all is implemented in the applications using
low level 3GL code.
OOA/D is not aware of that there are specialized systems intended to
manage the business logic freeing the applications from such task.
These systems are called DBMSs.
I don't know any programmer who knows what a DBMS really is :-(
Regards
Patrick May
> > Application logic, on the other hand, relates to the way in which
> > those business concepts are represented to users of an IT system.
> > This category includes details like GUI features, report formats,
> > and configurations to support non-functional requirements.
>
Some application logic deals with UIs, but UIs are not the only
element in that category. Non-functional requirements are issues such
as security, performance, quality of service, scalability,
reliability, and resiliency. The architecture, design, and logic to
support NFRs should not be coupled to the business logic because they
address different concerns and, again, they change for different
reasons.
"Non-functional requirements" is an industry standard term.
Anyone with experience developing even mid-sized systems should have
encountered it.
> > These two types of logic change for different reasons
>
> No, sometimes they change for related reasons, and sometimes they
> change for unrealated reasons. I have been observing app changes for
> more than a decade. Change comes in all kinds of directions and
> shapes.
"Sometimes they change for unrelated reasons." This is exactly
the point. Separating the two types of logic makes each set simpler
and minimizes the impact of changes that logically affect only one
set.
> > In any large system, unnecessary change must be minimized.
>
> Yes, and that is why code grouping requires a
> cost-benefit-probability analysis.
I have no idea what you mean by "code grouping" here. Design
decisions can be made without a formal cost/benefit analysis.
Typically what happens is that a change is made and someone raises an
issue like "Hey, that change had a serious ripple effect and broke
some unrelated, working code. We should refactor to decouple that
logic."
> > Separating these types of logic is just plain good engineering
> > practice.
>
> There is no impericle evidence saying that is the best choice. I see
> far more matra than I do careful risk analysis.
You seem to be arguing in favor of "big ball of mud"
applications. Architectures like MVC were developed to address real
problems discovered empirically when developing software. If you
haven't seen the need for decoupling, you haven't been working on
particularly large or complex systems.
> > The burden of proof is on the one making the assertion
>
> You guys asserted it should be separated. So.....
First of all, I'm typing this all by myself without any "guys"
around me. Second, you made the following assertion near the
beginning of this thread:
Personally I think the whole "separation" thing is horse
crap. The costs are higher than the benefits on average.
You made the claim. Where is your proof that the costs of separating
application and business logic are higher than the benefits, on
average?
Sincerely,
Patrick
PS: I'm still waiting for your evidence that encapsulation "gets in the
way", as you asserted in another thread.
Thomas Gagne
<snip>
>
> Besides, if it was a matter of plug-and-play swapping, then why not
> just write the client/server API's to do HTML instead? Many c/s systems
> talked thru API's rather than raw system calls, so just re-implement
> them for web. Why not? Because HTML is too limited to handle c/s API's.
Are you suggesting the business rules handle HTML formatting and UI? If a
user wants a hardcopy should the code now handling HTML, UI, and business
logic incorporate the output of PDF and various printer stuffs (color and B&W)
as well? Where does it end?
Following your logic you see no value to printer, disk, or graphic drivers?
Alfredo Novoa
<tga...@wide-open-west.com> wrote:
>Better to treat the database as a huge object that hides its data (table,
>rows, fields, organization, syntax, etc.) behind methods (stored procedures)
>which are the only way to transact with it.
Stored procedures are a very bad and primitive way to transact with a
DBMS.
It would be a lot better to use a high level declarative relational
language.
Regards
Thomas Gagne
Recommendations?
Patrick May
> On 27 Feb 2005 22:01:15 +0000, Patrick May <p...@spe.com> wrote:
> > The issue isn't GUIs or databases, it's the separation of
> > application logic and business logic. Business logic, in this
> > context, refers to the entities, rules, procedures, and processes
> > that represent and define the core functionality of the business.
> > Concepts like purchase orders, customers, service provisioning,
> > and billing fall into this category.
> >
> > Application logic, on the other hand, relates to the way in
> > which those business concepts are represented to users of an IT
> > system. This category includes details like GUI features, report
> > formats, and configurations to support non-functional
> > requirements.
>
> Agreed.
>
> Using less words: business logic are database constraint and
> derivation rules. Application logic is presentation logic.
I'll be the first to admit that my prose can often be shortened
with a net increase in clarity, but you've thrown the baby out with
the bathwater here. The business logic concepts I enumerated are at a
different level of abstraction from the implementation-specific
database constraints. Entities, rules, procedures, and processes can
be implemented in any number of ways. It is the concepts that are
important in the context of this discussion, not one way of specifying
those concepts.
Similarly, application logic is not limited to presentation logic
except in simple CRUD systems.
> OOA/D is not aware of that there are specialized systems intended to
> manage the business logic freeing the applications from such task.
>
> These systems are called DBMSs.
OOA/D isn't aware of anything -- it's just a set of techniques
for developing software. However, some of the best developers I've
had the pleasure of working with have extensive experience and
expertise with both OO and relational technology. They know, for
example, that DBMSs are one way to manage some types of business
logic. They also know that one size doesn't fit all, so they use the
appropriate tool for the job.
> I don't know any programmer who knows what a DBMS really is :-(
Perhaps you need to work with people who have experience in more
than one paradigm.
frebe
90s
> before the web was revealed to the unwashed masses. How great it was
for
> those of us with separated logic to easily and quickly front-end our
systems
> with HTML.
I spent (wasted) a number of years with developing "3-tier"
applications that did separate "business" logic from presentation
logic. The problem is that in the applications a worked with
(production control and human resource administration), 70% of the
logic was in the "thin" client. Switching from rich client to HTML
client still was a major task. And the price for this was a real code
bloat. Now I am using data-aware GUI components and is a much more
productive programmer.
> Would you rather your business logic be wrapped-up inside the
dumb-terminal
> code or that it be separated into its own layer?
It is impossible to have a client application with 0% "business logic".
But I agree that you should try to separate as much as possible of the
"business logic" from the client code.
> As far as databases are concerned it may not be that I'll change from
Oracle
> to Sybase, or SQL Server to DB2, but more likely that we'll need to
reorganize
> the database, move some fields, split some tables up, etc.,
Please give an example of a schema change you want to do, that will not
effect your "business logic" (or even presentation logic) too. A lot of
"business logic" is implemented in the database schema. The most common
schema changes is to add columns or tables, and doing this without
changing the rest of the application is a little bit pointless.
> and for the
> business layer to have hardwired itself to a specific table layout is
nearly
> as restrictive as mixing business and UI logic.
Why? Do you have some motivation for this?
> Better to treat the database as a huge object that hides its data
(table,
> rows, fields, organization, syntax, etc.) behind methods (stored
procedures)
> which are the only way to transact with it.
Using stored procedures will make you database vendor dependent. The
most important customer demand today is database independence. This
approach will also force you to write 1-10 stored procedures for every
table. This is a real code bloat. Besides, you will disable the
programmers to take real advantage of the functionality in a database.
Fredrik Bertilsson
http://butler.sourceforge.net
Alfredo Novoa
<tga...@wide-open-west.com> wrote:
Good DBMSs don't exist and there are not available implementations of
relational languages, but you can use any SQL dialect.
SQL dialects are messy pseudo relational languages. They are bad
languages, but they are a lot better way to transact with a DBMS than
a set of stored procedures.
It is a blunder to hide the database tables to the applications.
Regards
Alfredo Novoa
> The business logic concepts I enumerated are at a
>different level of abstraction from the implementation-specific
>database constraints.
Database constraints are purely logical concepts. They could not be
any other thing.
But you can implement database constraints in many ways.
One of the worst ways is to implement them on the applications using
procedural code, and that is what most (if not all) OOA/D books teach.
> Entities, rules, procedures, and processes can
>be implemented in any number of ways.
Agreed, and the best way is to implement them declaratively using a
good DBMS.
> It is the concepts that are
>important in the context of this discussion, not one way of specifying
>those concepts.
A database constraint is a rule and not a way to specify a rule.
> Similarly, application logic is not limited to presentation logic
>except in simple CRUD systems.
Application logic is not limited to presentation and communication
logic except in well designed systems which are very rare.
>> OOA/D is not aware of that there are specialized systems intended to
>> manage the business logic freeing the applications from such task.
>>
>> These systems are called DBMSs.
>
> OOA/D isn't aware of anything -- it's just a set of techniques
>for developing software.
A fuzzy set of techniques that often includes very bad techniques. One
of the most popular OOA/D techiques is to implement DBMSless systems.
> However, some of the best developers I've
>had the pleasure of working with have extensive experience and
>expertise with both OO and relational technology.
Relational technology is not available.
> They know, for
>example, that DBMSs are one way to manage some types of business
>logic.
DBMSs are THE WAY to manage business logic. If you don't know that
then you don't know what a DBMS really is.
To manage any business logic on the applications is a big design
fault.
> They also know that one size doesn't fit all, so they use the
>appropriate tool for the job.
Decent developement tools don't exist and we have to deal with very
poor tools.
It is true that sometimes we are forced to corrupt the design due to
the tool's flaws, but we are corrupting the design anyway.
>
>> I don't know any programmer who knows what a DBMS really is :-(
>
> Perhaps you need to work with people who have experience in more
>than one paradigm.
I don't need to work with more people with a lot of experience making
poor jobs, what I need is to work with people who knows the
theoretical foundations of the profession, but they are really hard to
find.
Regards
Alfredo Novoa
<fredrik_b...@passagen.se> wrote:
>logic. The problem is that in the applications a worked with
>(production control and human resource administration), 70% of the
>logic was in the "thin" client.
So you had 70% of application logic and 30% of business logic.
>Switching from rich client to HTML
>client still was a major task. And the price for this was a real code
>bloat. Now I am using data-aware GUI components and is a much more
>productive programmer.
Indeed, HTML clients are a giant backwards step.
>It is impossible to have a client application with 0% "business logic".
Why?
I don't see any reason, and such applications exist.
>But I agree that you should try to separate as much as possible of the
>"business logic" from the client code.
And it means to eliminate the 100% of the business logic from the
applications.
>Please give an example of a schema change you want to do, that will not
>effect your "business logic" (or even presentation logic) too.
A database design is a way to declare business logic. If you change
the database design you are changing the declared business logic. But
it is easy to imagine changes in the database design that does not
affect to the presentation logic. For instance to remove a constraint
or to replace a table by a view.
>Using stored procedures will make you database vendor dependent.
No, that will make you DBMS vendor dependent. But it is not reasonible
to pretend to be independent to the DBMS vendor.
It would be like to pretend to be language vendor independent.
> The
>most important customer demand today is database independence.
That is an astonishing statement.
> This
>approach will also force you to write 1-10 stored procedures for every
>table. This is a real code bloat. Besides, you will disable the
>programmers to take real advantage of the functionality in a database.
Agreed. It is a lot of work to build a very poor interface.
Regards
Patrick May
> > They know, for example, that DBMSs are one way to manage some
> > types of business logic.
>
> DBMSs are THE WAY to manage business logic. If you don't know that
> then you don't know what a DBMS really is.
I strongly suspect that my background gives me a better
understanding of the capabilities of the relational approach than you
have. I certainly understand that it has limitations, like any
technology, a fact which you seem not to recognize.
Your statement above demonstrates that you have an incredibly
myopic viewpoint, making communication between us impossible. I leave
the last word to you.
Thomas Gagne
<snip>
> It is a blunder to hide the database tables to the applications.
>
that to affect a transaction requiring only five parameters that as many as
seven tables are updated, two of them optionally? All the application need
know is the name of the procedure and the required parameters. If it becomes
necessary to update another table or move a column to another I can do so
without perturbing the application.
Or imagine an application with embedded SQL that needs to be optimized.
Having to ship a new program to production for such a minor fix is a blunder.
Better to be able to update the stored procedure without having to ship new
code.
Thomas Gagne
???
Why would it require 1-10 stored procedures for every table? No more or less
SQL exists to affect rules. It's only a matter of where they exist and to the
extent that location allows them to change independently of their customers.
If a programmer is worried such separation encourages code bloat they are
misinformed.
If anyone believes set theory is good for designing databases they should
consider applying normal-form to their processing. Code should exist once and
only once just as a fact does in a database (under optimal circumstances).
Though there are reasons to denormalize database design there are fewer
reasons to denormalize process design. Anything less is less-than correct, or
at least invites error.
Alfredo Novoa
>> > They know, for example, that DBMSs are one way to manage some
>> > types of business logic.
>>
>> DBMSs are THE WAY to manage business logic. If you don't know that
>> then you don't know what a DBMS really is.
>
> I strongly suspect that my background gives me a better
>understanding of the capabilities of the relational approach than you
>have.
I don't care about what your background is, but if you don't know that
DBMSs are intended to manage the business logic then you know very
very little about data management theory. Facts are facts and diplomas
decorate walls.
> I certainly understand that it has limitations, like any
>technology, a fact which you seem not to recognize.
To suggest that the relational approach is a technology shows a
profound ignorance.
BTW I was talking about DBMSs and not about the relational approach.
Another confusion to add to the list.
> Your statement above demonstrates that you have an incredibly
>myopic viewpoint, making communication between us impossible.
I was simply correcting a guy that was posting incorrect and
misleading information in a public newsgroup.
Regards
Alfredo Novoa
<tga...@wide-open-west.com> wrote:
>We'll have to agree to disagree on that point. Why should an application know
>that to affect a transaction requiring only five parameters that as many as
>seven tables are updated, two of them optionally?
You are assuming a procedural interface and DBMSs should be accessed
using declarative interfaces.
> All the application need
>know is the name of the procedure and the required parameters.
All the application needs to do is to declare the transaction.
> If it becomes
>necessary to update another table or move a column to another I can do so
>without perturbing the application.
Nothing of this is neccessary with a declarative approach.
>Or imagine an application with embedded SQL that needs to be optimized.
SQL optimization is a task for the DBMS. If your DBMS is not able to
optimize the queries then you have a poor DBMS.
>Having to ship a new program to production for such a minor fix is a blunder.
> Better to be able to update the stored procedure without having to ship new
>code.
But you need to ship code to update an stored procedure.
Regards
Alfredo Novoa
<tga...@wide-open-west.com> wrote:
>Why would it require 1-10 stored procedures for every table?
Well, in fact we require 0 stored procedures per table. The best code
is the code we can eliminate. No code = no work and no bugs.
Using a high level declarative language you can avoid almost all
business logic procedural code.
>If anyone believes set theory is good for designing databases they should
>consider applying normal-form to their processing.
Consideration is not enough, you should apply normalization.
> Code should exist once and
>only once just as a fact does in a database (under optimal circumstances).
But it is a lot better that it exists never.
>Though there are reasons to denormalize database design there are fewer
>reasons to denormalize process design.
We can sumarize all that reasons in one: the DBMS is poorly designed
and/or implemented.
With a decent DBMS denormalization is never necessary.
But there are tricks to achieve good performance with normalized
designs even with poor DBMSs.
Regards
frebe
> >It is impossible to have a client application with 0% "business
logic".
> Why?
> I don't see any reason, and such applications exist.
There are a lot of input validation code in clients. Separating every
form of input validation to a "business layer" would cause code bloat.
Process workflow is also "hardcoded" into the client.
> But it is not reasonible
> to pretend to be independent to the DBMS vendor.
I do.
> > The
> >most important customer demand today is database independence.
> That is an astonishing statement.
I would say it is almost impossible to sell enterprise applications
today, if you don't support both Oracle and SQL Server.
Fredrik Bertilsson
http://butler.sourceforge.net
frebe
or less
> SQL exists to affect rules. It's only a matter of where they exist
and to the
> extent that location allows them to change independently of their
customers.
The problem is that in stored procedures, SQL statements are
hard-coded. Lets say that you have a client there the user can choose
the sort order. The easiest way to solve this is by letting the client
dynamically generate the SQL based on the user selection. If you use
stored procedures, the need one procedure for every possible sort order
combination.
In many cases (but not all), a specific SQL is only called from one
point in the application. Identical SQL statements that are called from
multiple points should of course be separated in a
procedure/class/layer. But doint this for every single SQL, just becase
it is a SQL, that is code bloat. This is analogous to other code
fragements. You only them into separate procedures if they are called
from multiple points in your application. (Sometimes you separate them
because you want to improve readablity, but that is just a cosmetical
reason.)
Fredrik Bertilsson
http://butler.sourceforge.net
Alfredo Novoa
<fredrik_b...@passagen.se> wrote:
>Alfredo Novoa wrote:
>> >It is impossible to have a client application with 0% "business
>logic".
>> Why?
>> I don't see any reason, and such applications exist.
>
>There are a lot of input validation code in clients.
So you are saying that it is impossible to have applications without
business logic checking code because applications have business logic
checking code. Great :)
> Separating every
>form of input validation to a "business layer" would cause code bloat.
Moving all the busness rules validation to a good DBMS would cause
massive code savings.
>I would say it is almost impossible to sell enterprise applications
>today, if you don't support both Oracle and SQL Server.
I have not detected that. Customers only demand working systems at low
price, they don't care about the boring dirty details.
I know many people who only support SQL Server or Oracle. Specially in
tailored systems.
I know systems that support several DBMSs but they misuse the DBMSs as
dumb file managers. So they are DBMSless systems.
A better solution would be to use a relational middleware like this:
http://www.alphora.com/tiern.asp?ID=DATAPHOR2
Regards
Alfredo Novoa
<fredrik_b...@passagen.se> wrote:
> Identical SQL statements that are called from
>multiple points should of course be separated in a
>procedure/class/layer.
Or even better: in a view.
Regards
frebe
> Moving all the busness rules validation to a good DBMS would cause
> massive code savings.
In many cases you want to have interactive validation in your GUI. Lets
say we have a text field for entering telephone numbers. Some DBMS can
validate that a column value is a valid telephone number, but it much
better to have a feature like a key listener that only allows the user
to enter valid characters. I would classify such logic as "business
logic". I agree with you that a lot of business rules can be validated
by a DBMS, but not all.
> >I would say it is almost impossible to sell enterprise applications
> >today, if you don't support both Oracle and SQL Server.
> I have not detected that. Customers only demand working systems at
low
> price, they don't care about the boring dirty details.
Obviously we have different customers... Maybe my company have very
strange customers.
> I know many people who only support SQL Server or Oracle. Specially
in
> tailored systems.
Tailored systems only have one customer, so obviously the need for
database vendor independence is much smaller.
> I know systems that support several DBMSs but they misuse the DBMSs
as
> dumb file managers. So they are DBMSless systems.
Most DBMS vendors support a rather large subset of the ANSI SQL
standard. It is possible to do much more than just dumb "file
operations" only using ANSI SQL.
Fredrik Bertilsson
http://butler.sourceforge.net
Thomas Gagne
frebe wrote:
>>Why would it require 1-10 stored procedures for every table? No more
>
> or less
>
>>SQL exists to affect rules. It's only a matter of where they exist
>
> and to the
>
>>extent that location allows them to change independently of their
>
> customers.
>
> The problem is that in stored procedures, SQL statements are
> hard-coded. Lets say that you have a client there the user can choose
> the sort order. The easiest way to solve this is by letting the client
> dynamically generate the SQL based on the user selection. If you use
> stored procedures, the need one procedure for every possible sort order
> combination.
alternative 1) use dynamic SQL. Build the query in a string (inside the
proc) and execute it
alternative 2) don't revisit the database just because the user wants to
resort the output. Sort it inside the application server. Save the
results with the session in case they change their mind again.
>
> In many cases (but not all), a specific SQL is only called from one
> point in the application. Identical SQL statements that are called from
> multiple points should of course be separated in a
> procedure/class/layer. But doint this for every single SQL, just becase
> it is a SQL, that is code bloat. This is analogous to other code
> fragements. You only them into separate procedures if they are called
> from multiple points in your application. (Sometimes you separate them
> because you want to improve readablity, but that is just a cosmetical
> reason.)
Or you want to improve the ability to browse the code. Or you want to
insulate the application from dependencies on how the data is stored and
having SQL inside the application breaks it. Or you anticipate there
may be other client applications wanting to do the same thing and you
can't allow them running SQL, or you don't want to update two clients
(and redeploy) for a what would otherwise be a minor database change.
By putting SQL inside your clients you are multiplying the expense of
changes to the DB.
Our staff works with a pretty basic rule. There is no SQL in
applications. The code bloat is imaginary. The cost of change is not,
and change is guaranteed.
Thomas Gagne
the database organizes data (through the view) which exceeds my
threshhold of lower coupling.
Alfredo Novoa
wrote:
>> Moving all the busness rules validation to a good DBMS would cause
>> massive code savings.
>
>In many cases you want to have interactive validation in your GUI.
So what is the problem?
There are systems with interactive validation in the GUI that
implement the business logic using a DBMS. It is very easy.
> Lets
>say we have a text field for entering telephone numbers. Some DBMS can
>validate that a column value is a valid telephone number,
All DBMSs. If something can not validate that then it is not a DBMS.
DBMSs are computationally complete. If something is not
computationally complete then it is not a DBMS.
> but it much
>better to have a feature like a key listener that only allows the user
>to enter valid characters.
It is much worse because you have to duplicate the functionality and
the application programming languages are much less powerful for such
validations.
> I would classify such logic as "business
>logic". I agree with you that a lot of business rules can be validated
>by a DBMS, but not all.
This is plain wrong. DBMSs are turing complete so they can validate
the same rules as any low level procedural application language like
Java.
>> I know systems that support several DBMSs but they misuse the DBMSs
>as
>> dumb file managers. So they are DBMSless systems.
>
>Most DBMS vendors support a rather large subset of the ANSI SQL
>standard. It is possible to do much more than just dumb "file
>operations" only using ANSI SQL.
Indeed, but the fact is that most enterprise systems use DBMSs as dumb
file managers.
Regards
Alfredo Novoa
<tga...@wide-open-west.com> wrote:
>Views are better than SQL, but still represent a dependency between how
>the database organizes data
No!
DBMSs are intended to decouple the applications to the databases.
If you use a DBMS then your applications don't have access to the
database. They have access to the DBMS and the DBMS manages the
database.
Thanks to DBMSs the applications don't need to know anything about the
physical database organization.
On the other hand the logical structures that the DBMS show to the
applications are exactly all that the application programmers need to
know, and in the case of SQL DBMSs, SQL is the language intended to
communicate the applications with the DBMS.
All this should be explained in the first class of any elementary
database course.
Regards
Thomas Gagne
> On Tue, 01 Mar 2005 11:52:03 -0500, Thomas Gagne
> <tga...@wide-open-west.com> wrote:
>
>
>>Views are better than SQL, but still represent a dependency between how
>>the database organizes data
>
>
> No!
>
> DBMSs are intended to decouple the applications to the databases.
>
> If you use a DBMS then your applications don't have access to the
> database. They have access to the DBMS and the DBMS manages the
> database.
Just because the database hides the organization of the data and index
on disk, and I needn't worry about page allocations, leaf nodes, etc.,
doesn't mean the design should be exposed and that the application
programmer is already sufficiently decoupled from the database. They
are not.
If an application programmer thinks SQL is a sufficient abstraction and
they are unable to imagine how something as trivial as renaming a column
might perturb their application then their company deserves the expense
and complaints from its customers.
Physical abstraction is simply not enough. Do you remember how
applications used to link with enormous DB libraries because each
application's logical address space included the functions for
manipulating the data on disk? Do you remember Oracle 5.x? Infos? Or
any other pre-1988 DB (relational or not)? According to your logic
these applications were sufficiently insulated from changes to the
database because the subroutines were handling the physical access, but
they were still tightly bound by virtue of being linked with the
libraries. Any changes to physical organization necessitated a relink
and redeployment. Your logic is consistent, though, in that a logical
reorganization will require an edit, recompile. relink, and redeployment
of the application.
No!
Alfredo Novoa
<tga...@wide-open-west.com> wrote:
>Just because the database hides the organization of the data and index
The DBMS, not the database. You confuse databases with DBMSs all the
time. But you don't confuse only the terms, you also confuse the
concepts behind the terms what is a lot worse.
>on disk, and I needn't worry about page allocations, leaf nodes, etc.,
>doesn't mean the design should be exposed and that the application
>programmer is already sufficiently decoupled from the database.
No, but if the expossed database structure is a well designed
relational structure then it is sufficient, because a relational
database is the best way to logically represent information at the
current date and with almost certainty also in the foreseeable future.
DBMSs were created just for that, to decouple the applications from
the database, and RDBMSs are the best DBMSs for that.
>If an application programmer thinks SQL is a sufficient abstraction and
>they are unable to imagine how something as trivial as renaming a column
>might perturb their application then their company deserves the expense
>and complaints from its customers.
This is exactly the contrary!
If you rename an stored procedure you will cause perturbation to the
applications. But if you rename a table, you can hide the table to the
users and to create a view which has the same name and structure of
the old table, and the applications will be unaffected. This is called
logical independence: applications are immune to changes in the
logical structures.
In fact the exposed structures are what decouple the applications from
the database. You might change the database all what you want
(physically and logically) without changing the exposed structure and
the applications will remain unaffected.
You lack knowledge that any student with a few hours of instruction in
data management theory should have. This would be scandalous on any
other profession.
>Physical abstraction is simply not enough.
DBMSs expose logical structures, and the Relational Model provides the
necessary abstraction level.
> Do you remember how
>applications used to link with enormous DB libraries because each
>application's logical address space included the functions for
>manipulating the data on disk?
Such primitive file processing libraries have very little to do with
DBMSs.
> Do you remember Oracle 5.x? Infos? Or
>any other pre-1988 DB (relational or not)?
No, I was in the high school. But those DB products were very limited
by the puny capabilities of the personal computers of that age. Now we
can use a lot more sophisticated solutions.
> According to your logic
>these applications were sufficiently insulated from changes to the
>database because the subroutines were handling the physical access
No, I never said that.
> Any changes to physical organization necessitated a relink
>and redeployment.
And that is not needed if you use a DBMS.
> Your logic is consistent, though, in that a logical
>reorganization will require an edit, recompile. relink, and redeployment
>of the application.
That is not required thanks to the logical independence.
Regards
frebe
> If an application programmer thinks SQL is a sufficient abstraction
and
> they are unable to imagine how something as trivial as renaming a
column
> might perturb their application then their company deserves the
expense
> and complaints from its customers.
This stupid argument pops up all the time. Can you rename a class or
method without doing a lot of changes in the rest of the application?
Every time you change the name of an element in an interface, you have
problem. Can you give me some example why renaming a column would be
necessary?
Fredrik Bertilsson
http://butler.sourceforge.net
frebe
> resort the output. Sort it inside the application server. Save the
> results with the session in case they change their mind again.
Soon your application server will be a DBMS.
> Or you want to improve the ability to browse the code.
Separating SQL statements will also decrease readability in your code.
The programmer has to open the SQL source file to find out what the SQL
actually do.
> Or you want to
> insulate the application from dependencies on how the data is stored
and
> having SQL inside the application breaks it.
A database schema does not show "how the data is stored". In fact, a
DMBS may not store the data at all. It can be all-in-memory.
> Or you anticipate there
> may be other client applications wanting to do the same thing and you
> can't allow them running SQL
Why? It is just to make a (web) service that takes a SQL string as
argument and returns an XMLifed resultset, and any client can run SQL.
> or you don't want to update two clients
> (and redeploy) for a what would otherwise be a minor database change.
Please give an example of such database change.
Fredrik Bertilsson
http://butler.sourceforge.net
frebe
> >In many cases you want to have interactive validation in your GUI.
> So what is the problem?
> There are systems with interactive validation in the GUI that
> implement the business logic using a DBMS. It is very easy.
If I have a text field for telephone number and I don't want the user
to enter invalid characters, how can the DBMS do this for me? I think I
need something like a key listener. Before the user press the "Save"
button, there is no interaction to the DBMS. Please give an example how
this could be solved your way.
> > but it much
> >better to have a feature like a key listener that only allows the
user
> >to enter valid characters.
> It is much worse because you have to duplicate the functionality and
> the application programming languages are much less powerful for such
> validations.
I agree, but it is not always possible to wait with input validation
until the "Save"-button is pressed. I solve this problem with
data-aware GUI components that are also aware of database metadata. The
problem is with customized datatype like telephone number. The GUI
component need a regular expression for valid telephone numbers. I
don't think it is possible to associate a datatype/domain with a
regular expression in the DBMS, using standardized API:s like JDBC,
ODBC or ADO.
> > I would classify such logic as "business
> >logic". I agree with you that a lot of business rules can be
validated
> >by a DBMS, but not all.
> This is plain wrong. DBMSs are turing complete so they can validate
> the same rules as any low level procedural application language like
> Java.
If you put your entire application (including the GUI) inside the DBMS,
you are correct. But as soon as you want to have parts of your
application outside the DBMS, there are "business logic" outside it.
Fredrik Bertilsson
http://butler.sourceforge.net
Alfredo Novoa
wrote:
>If I have a text field for telephone number and I don't want the user
>to enter invalid characters, how can the DBMS do this for me?
Rejecting the database update petition when it is done.
But if I understand you correctly what you want is that the invalid
characters will not be presented on the screen before the user press
the save button.,This is not business logic, it is presentation
(application) logic, but it is easy to implement with data-aware
controls that are initialized with database metadata.
Business logic guarantee that the database will not be in an
inconsistent state, but it is not about what a GUI displays, specially
before user acceptation.
> I think I
>need something like a key listener. Before the user press the "Save"
>button, there is no interaction to the DBMS.
Before the user press the "Accept" button (or any other acceptation
action) there is not business logic validation, only presentation
logic validation.
>I agree, but it is not always possible to wait with input validation
>until the "Save"-button is pressed. I solve this problem with
>data-aware GUI components that are also aware of database metadata.
I do the same.
> The
>problem is with customized datatype like telephone number. The GUI
>component need a regular expression for valid telephone numbers. I
>don't think it is possible to associate a datatype/domain with a
>regular expression in the DBMS, using standardized API:s like JDBC,
>ODBC or ADO.
It is possible if you have a regular expressions library that you
might add to your DBMS. It is rather easy if you use SQL Server 2005.
But I prefer to decompose the complex "fields" in the GUI instead to
use regular expressions. I use data-aware component key filtering with
primitive types only.
IMO we disagree only in semantic issues.
Regards
Robert C. Martin
wrote:
There are a million reasons. A simple example is the rather new
distinction between mailing address and billing address. A few years
ago a customer table might simply have had an 'address' column. But
with the advent of internet credit card payments it is likely that
many customer tables now need 'billing-address' columns. It would be
sloppy to leave the old column named simply 'address'. It should be
renamed to 'mailing-address'.
I am currently working with a client that is suffering mightily from
schema changes. Every time the DBAs make a change to the schema, the
software thrashes, and the test systems thrash. One could argue (and
I do) that the design of their system is too sensitive to schema
changes. Unfortunately the number of software systems that show that
sensitivity is very high.
By following good design and dependency management principle, a system
can be made quite insensitive to schema changes. Unfortunately too
many young software developers think that time-to-market is an excuse
not to learn and follow good design principles. They have not yet
learned that following good design principles will make them go
faster, even in the short term.
-----
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
frebe
> distinction between mailing address and billing address. A few years
> ago a customer table might simply have had an 'address' column. But
> with the advent of internet credit card payments it is likely that
> many customer tables now need 'billing-address' columns. It would be
> sloppy to leave the old column named simply 'address'. It should be
> renamed to 'mailing-address'.
If you had a customer class with a property 'address', would you rename
it to 'mailing-address' and break backward compatibility just because
it is "sloppy" not to do it?
Probably you would create a new property 'mailing-address' without
removing the old 'address' property. The same could be done in a
database by creating a view that have both the old and new column name.
Now you have 999999 resons left. Please give me a better reson.
> Every time the DBAs make a change to the schema, the
> software thrashes,
In that case your client should fire his DBA. If you had a programmer
that keep doing changes in the object model that causes the software to
crash, what would you do with him?
Fredrik Bertilsson
http://butler.sourceforge.net
Alfredo Novoa
<uncl...@objectmentor.com> wrote:
>I am currently working with a client that is suffering mightily from
>schema changes. Every time the DBAs make a change to the schema, the
>software thrashes, and the test systems thrash.
But why the DBA changes the structures exposed to the old
applications?
It is completely unnecessary.
A DBA might create as many different database external views as is
necessary.
>By following good design and dependency management principle, a system
>can be made quite insensitive to schema changes. Unfortunately too
>many young software developers think that time-to-market is an excuse
>not to learn and follow good design principles. They have not yet
>learned that following good design principles will make them go
>faster, even in the short term.
But the problem you described seems to be a DBA's fault instead of an
application developers' fault.
But these problems would not exist with tools with a better
integration between applications and DBMSs
Regards
topmind
Anyone with experience developing even mid-sized systems should have
encountered it. *)
>From a web-search, it appears to be associated with specific
methodologies that some shops use and some don't.
(* "Sometimes they change for unrelated reasons." This is exactly
the point. Separating the two types of logic makes each set simpler
and minimizes the impact of changes that logically affect only one
set. *)
Could you please clarify.
(* Design decisions can be made without a formal cost/benefit analysis.
*)
I did not mean to imply it had to be formal. Perhaps for newbies it
should, but experienced developers hopefully can do it fairly quick in
their head.
(* Typically what happens is that a change is made and someone raises
an
issue like "Hey, that change had a serious ripple effect and broke
some unrelated, working code. We should refactor to decouple that
logic." *)
You have to be careful with that. Just because a change favors grouping
A *this* time does not necessarily mean future changes will also favor
grouping A. One change is not enough to justify such a change.
(* You seem to be arguing in favor of "big ball of mud"
applications. *)
No, I use a well-tested methodology.
(* Architectures like MVC were developed to address real
problems discovered empirically when developing software. *)
I personally find MVC to be crap.
(* If you haven't seen the need for decoupling, you haven't been
working on
particularly large or complex systems. *)
If by "decoupling" you mean indirection, then I would say it depends on
the cost/risk analysis. Indirection is not free. Spend it wisely.
(* You made the claim. Where is your proof that the costs of
separating
application and business logic are higher than the benefits, on
average? *)
Tell me. If neither side supplies proof, what is the default?
-T-
topmind
>> just write the client/server API's to do HTML instead? Many c/s
systems
>> talked thru API's rather than raw system calls, so just re-implement
>> them for web. Why not? Because HTML is too limited to handle c/s
API's.
(* Are you suggesting the business rules handle HTML formatting and UI?
If a
user wants a hardcopy should the code now handling HTML, UI, and
business
logic incorporate the output of PDF and various printer stuffs (color
and B&W)
as well? Where does it end? Following your logic you see no value to
printer, disk, or graphic drivers? *)
Devices usually use very low-level "languages". HTML is not a low-level
language. If you don't use HTML as your output language, then you will
have to use something else. Is that something else significantly better
than HTML such that it should be used instead? You could just be
reinventing wheels to get yet more wheels.
I am not quite sure what your PDF-versus-HTML issue is. Please clarify.
You gotta pick SOME kind of document language for the app to talk to.
-T-
Robert C. Martin
wrote:
>> There are a million reasons. A simple example is the rather new
>> distinction between mailing address and billing address. A few years
>> ago a customer table might simply have had an 'address' column. But
>> with the advent of internet credit card payments it is likely that
>> many customer tables now need 'billing-address' columns. It would be
>> sloppy to leave the old column named simply 'address'. It should be
>> renamed to 'mailing-address'.
>
>If you had a customer class with a property 'address', would you rename
>it to 'mailing-address' and break backward compatibility just because
>it is "sloppy" not to do it?
Yes, wouldn't you? This is a two click operation in my IDE of choice.
>Probably you would create a new property 'mailing-address' without
>removing the old 'address' property. The same could be done in a
>database by creating a view that have both the old and new column name.
I would not do that in source code, and I would not do that in a
database. I don't want a lot of cruft accumulating in my code, or my
schemae.
>> Every time the DBAs make a change to the schema, the
>> software thrashes,
>
>In that case your client should fire his DBA. If you had a programmer
>that keep doing changes in the object model that causes the software to
>crash, what would you do with him?
I'd fire the architects that created a system that was so sensitive to
change.
topmind
distinction between mailing address and billing address. A few years
ago a customer table might simply have had an 'address' column. But
with the advent of internet credit card payments it is likely that
many customer tables now need 'billing-address' columns. It would be
sloppy to leave the old column named simply 'address'. It should be
I would probably leave it as "address". In the data dictionary put a
note about the new nature of it. (Unfortunately, many DB's don't have
description fields in their schema/d-dictionary.)
But perhaps a better fix is to create a Contact table and use a
one-to-many relationship (with foriegn keys billAddressID,
shipAddressID, etc.) Perhaps "address" can then be view mapped into one
of the contact relationships. Unfortunately, most RDBMS don't have
"view columns", only view tables.
Note that these kinds of issues are not just a RDBMS issue. No matter
what the interface is into addresses, you face the same issue. Your OO
class will still have methods named "address" instead of
"mailingAddress". The exact same issue is still staring at you. Putting
more layers of indirection only make more layers that have to change.
It is true that many existing RDBMS don't have enough view
(abstraction) options, which is not the fault of relational but the
implementation, but that is not the problem in this instance.
Class, repeat after me: "INDIRECTION IS NOT FREE"
Daniel Parker
news:perc21dsdinim56lh...@4ax.com...
> On 2 Mar 2005 07:29:09 -0800, "frebe" <fredrik_b...@passagen.se>
> wrote:
>
>>If you had a customer class with a property 'address', would you rename
>>it to 'mailing-address' and break backward compatibility just because
>>it is "sloppy" not to do it?
>
> Yes, wouldn't you? This is a two click operation in my IDE of choice.
>
method addElement from the Vector class, since that name has become
inconsistent with later naming conventions. But that isn't the issue, any
more than it is in your example. If you change an interface, whether it's
the interface to your customer object or a view in an RDBMS, the impact
depends upon the number of users of that interface. If you have a
relatively small project, say a few thousand classes and a few hundred
tables, and it's a small team that basically owns that project, with no
external users, then you can refactor to your heart's content, and change
just about anything, table names, attribute names, method names, whatever.
And if the project is bigger, there's lots of ways of managing change,
branching, merging, what have you.
But if you have external users, you have to be careful. One way is not to
change old interfaces, add new ones instead. Migrate all users to the new
ones if the names are that important, if the customer approves, if you can
justify the cost.
A database schema, or as much of it as the DBA wants to expose, represents
an interface, not physical storage. The same issues apply to it as apply to
any other interfaces, including the interfaces to your business objects.
I agree with frebe, it sounds like your DBA doesn't know what he's doing.
Regards,
Daniel Parker
Thomas Gagne
<snip>
>
> Class, repeat after me: "INDIRECTION IS NOT FREE"
>
Nothing is free. Interpreters are more expensive than compiled
languages. C is more expensive than assembly, assembly more expensive
than microcode, and microcode more expensive than, well, I don't know
enough about hardware.
But in the meantime, CPUs are more powerful and less expensive, networks
have more bandwidth and are less expensive, memory is cheaper and
denser, hard drive capacity has gone up, become denser, and less expensive.
The one that that hasn't gotten cheaper is designers and programmers.
Software requirements have gotten more complex, not less. Technologies
have become more numerous. If abstraction improves productivity and it
costs only some indirection, I will gladly pay it.
Daniel Parker
> On 1 Mar 2005 21:29:26 -0800, "frebe" <fredrik_b...@passagen.se>
>>Can you give me some example why renaming a column would be
>>necessary?
>
> There are a million reasons. A simple example is the rather new
> distinction between mailing address and billing address. A few years
> ago a customer table might simply have had an 'address' column. But
> with the advent of internet credit card payments it is likely that
> many customer tables now need 'billing-address' columns. It would be
> sloppy to leave the old column named simply 'address'. It should be
> renamed to 'mailing-address'.
>
Your customer probably doesn't care. You care, but your customer doesn't
care about you. Try writing "change column names" on one of your little
cards, and see where that card ends up in the pile.
Regards,
Daniel Parker
frebe
> >If you had a customer class with a property 'address', would you
rename
> >it to 'mailing-address' and break backward compatibility just
because
> >it is "sloppy" not to do it?
> Yes, wouldn't you? This is a two click operation in my IDE of
choice.
Breaking interfaces is a very bad behaivor in software engineering. It
is not a two-click operation, you need to change every call of this
property in the rest of the application. I am very surprised to have
this answer from you. One of the best thing with OO is the concept of
interfaces. But if you break the interface, the advantage is gone.
> >Probably you would create a new property 'mailing-address' without
> >removing the old 'address' property. The same could be done in a
> >database by creating a view that have both the old and new column
name.
> I would not do that in source code, and I would not do that in a
> database. I don't want a lot of cruft accumulating in my code, or my
> schemae.
Anyway, this is the way everyone that are doing component libraries has
to work. If you use to break the interfaces, your customers/users will
soon leave you.
I don't really understand why you need to change the name of 'address'
at all. The semantics of the column was the same before and after the
addition of the new column. The fact that you added another column
doesn't change the meaning of the first. And this is just a name used
by the programmer. What label you want to show to the user is a
completly different story.
> >> Every time the DBAs make a change to the schema, the
> >> software thrashes,
> >In that case your client should fire his DBA. If you had a
programmer
> >that keep doing changes in the object model that causes the software
to
> >crash, what would you do with him?
> I'd fire the architects that created a system that was so sensitive
to
> change.
How could you accept a DBA that changes the schema in a non backward
compatible way?
Fredrik Bertilsson
http://butler.sourceforge.net
frebe
> characters will not be presented on the screen before the user press
> the save button
Every time the user types a character, I want the key lister to either
accept it or reject it. The DBMS can't be called every time the user
presses a key.
> Before the user press the "Accept" button (or any other acceptation
> action) there is not business logic validation, only presentation
> logic validation.
I consider the type of validation I described above, as "business"
validation.
> It is possible if you have a regular expressions library that you
> might add to your DBMS. It is rather easy if you use SQL Server 2005.
I know that there are DBMS that can do "everything". In Oracle you can
put your entire application inside the database. When I talk about
inside or outside the DBMS, I am refering to what you can do with an
average DBMS using standard interfaces such as JDBC/ODBC/ADO.
> IMO we disagree only in semantic issues.
I am not sure that we disagree at all. If I worked in the same team as
you, I would be happy.
Fredrik Bertilsson
http://butler.sourceforge.net
Ilja Preuß
> Breaking interfaces is a very bad behaivor in software engineering. It
> is not a two-click operation, you need to change every call of this
> property in the rest of the application.
Which *is* a two-click operation in modern IDEs.
Cheers, Ilja
Patrick May
> > "Non-functional requirements" is an industry standard term.
> > Anyone with experience developing even mid-sized systems should
> > have encountered it.
>
> methodologies that some shops use and some don't.
This is not the case. It is a standard term, widely used to
describe certain qualities required of systems of even relatively
small size.
> > "Sometimes they change for unrelated reasons." This is exactly
> > the point. Separating the two types of logic makes each set
> > simpler and minimizes the impact of changes that logically affect
> > only one set.
>
> Could you please clarify.
When no effort is made to decouple application and business
logic, the result is that nearly every component of the system
includes both types. A change to a business rule, for example, could
impact the code of a message queue adapter. This increases the risk
that a working application artifact could be broken by a change that
should not logically have impacted it. It also means that each
component is doing more than it should, and is therefore more complex
than necessary. See Robert Martin's paper on the Single
Responsibility Principle for a good explanation of why this is bad
engineering practice.
> > Typically what happens is that a change is made and someone raises
> > an issue like "Hey, that change had a serious ripple effect and
> > broke some unrelated, working code. We should refactor to
> > decouple that logic."
>
> You have to be careful with that. Just because a change favors
> grouping A *this* time does not necessarily mean future changes will
> also favor grouping A. One change is not enough to justify such a
> change.
The example was in response to your statement that "code-grouping
requires a cost-benefit analysis". I still don't know what you mean
by "code-grouping", but a real, recognized, unnecessary impact is a
good indication that refactoring is required. If it turns out that a
future change requires a different refactoring, that is a good
indication that the design needs more thought.
> > You seem to be arguing in favor of "big ball of mud" applications.
>
> No, I use a well-tested methodology.
I'm not aware of a methodology that encourages the tight coupling
of application and business logic. What methodology do you use?
> > If you haven't seen the need for decoupling, you haven't been
> > working on particularly large or complex systems.
>
> If by "decoupling" you mean indirection, then I would say it depends
> on the cost/risk analysis. Indirection is not free. Spend it wisely.
Indirection is one means of achieving decoupling, but by no means
the only one. What forms of indirection do you find to be so
expensive that they should be avoided?
> > You made the claim. Where is your proof that the costs of
> > separating application and business logic are higher than the
> > benefits, on average?
>
> Tell me. If neither side supplies proof, what is the default?
The default is that the person making the unsubstantiated claim
retracts it and apologizes for wasting the time of the other people
participating in the discussion. This, of course, assumes a minimum
level of intellectual integrity on the part of the claimant. You have
recently made two claims without providing evidence, namely:
- Encapsulation "gets in the way".
- In reference to separating application and business logic:
"Personally I think the whole 'separation' thing is horse
crap. The costs are higher than the benefits on average."
Will you be substantiating these assertions or retracting them? (The
only other alternative, a lack of intellectual integrity on your part,
is of course not worthy of suggestion.)
Sincerely,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
p...@spe.com | (C++, Java, ObjectStore, Oracle, CORBA, UML)
frebe
Only, if you have all source that are using the broker interface in
your IDE. In larger applications/projects it is normally impossible to
have ALL source in the IDE. And if you are writing classes that are
used by other projects, your way is of course impossible.
Even if you have access to all source that are using your broken
interface, there are a deployment problem. All binaries has to be
redeployed because of this stupid change, and you will risk having
compatibility problems in your runtime environment.
I thought that not breaking interfaces, was something teached in every
basic OO course.
I could also say like this: Using the right tool, a rename of a
database column is a "two-click operation".
Fredrik Bertilsson
http://butler.sourceforge.net
Alfredo Novoa
wrote:
>(* Architectures like MVC were developed to address real
>problems discovered empirically when developing software. *)
>
>I personally find MVC to be crap.
It is not whether it is properly implemented.
In a business system it should be:
Model: the database relational design
View: the applications
Controller: the DBMS.
That's simple!
What is crap is to create monolithic DBMSless applications.
Regards
Alfredo Novoa
wrote:
>I could also say like this: Using the right tool, a rename of a
>database column is a "two-click operation".
Indeed.
Regards
Alfredo Novoa
wrote:
>> But if I understand you correctly what you want is that the invalid
>> characters will not be presented on the screen before the user press
>> the save button
>
>Every time the user types a character, I want the key lister to either
>accept it or reject it. The DBMS can't be called every time the user
>presses a key.
Well, I agree on that it is not necessary to call the DBMS to filter
the characters of a text box, but I develop incremental search dialogs
which call the DBMS every time the user presses a key.
It is really fast if you use a good distributed DBMS.
>> Before the user press the "Accept" button (or any other acceptation
>> action) there is not business logic validation, only presentation
>> logic validation.
>
>I consider the type of validation I described above, as "business"
>validation.
But the actual meaning of the rule is: a phone number edit box must
not show incorrect characters when an user is introducing a phone
number.
I don't consider that a business rule.
>I know that there are DBMS that can do "everything".
As I said before, if something can not do "everything" then it is not
a DBMS.
>put your entire application inside the database. When I talk about
>inside or outside the DBMS, I am refering to what you can do with an
>average DBMS using standard interfaces such as JDBC/ODBC/ADO.
And I am talking about what you could do with an ideal DBMS using an
ideal interface.
Regards
Thomas Gagne
frebe wrote:
<snip>
>
> I thought that not breaking interfaces, was something teached in every
> basic OO course.
It is. That's why things should be loosely coupled. SQL is an
interface, tables names, column names, and relationships when known in
both the database (necessary) and the application (unnecessary) creates
a tighter coupling between them.
>
> I could also say like this: Using the right tool, a rename of a
> database column is a "two-click operation".
It may be, as long as (as you point out) it doesn't disturb the
interface between it and the application. If it does, you're shipping
binaries...
Daniel Parker
news:d06f39$b7n$1...@stu1id2.ip.tesion.net...
method from Vector. Nothing to do with the issue at hand. You don't see
that? Haven't you ever written an interface that got used outside of the
bounndaries of your own little world?
It's a little more work, not much more, to find all the occurances of a
table column name in your text files. Again, that's not the issue. The
only difference is that database schemas tend to get reused a little more so
that the real issue, the number of external clients of that interface,
becomes more apparent.
Regards,
Daniel Parker
frebe
every
>> basic OO course.
> It is. That's why things should be loosely coupled. SQL is an
> interface,
in a programming language, right?
> tables names, column names, and relationships when known in
> both the database (necessary) and the application (unnecessary)
creates
> a tighter coupling between them.
There are always a tight coupling between the interface and the user of
the interface. The good thing with an interface (like ANSI SQL) is that
is does not have a tight coupling to the implementation (DBMS product).
I don't understand how you can both claim SQL to be an interface
(correct) and that SQL should be loosely coupled (wrong). It like
having a method MyClassA::methodA that are used by MyClassB::methodB,
and you should be able to rename methodA without renaming methodB.
I am still waiting for you to provide some reasonable reasons why
columns should be renamed.
Fredrik Bertilsson
http://butler.sourceforge.net
Alfredo Novoa
<tga...@wide-open-west.com> wrote:
>It is. That's why things should be loosely coupled. SQL is an
>interface, tables names, column names, and relationships when known in
>both the database (necessary) and the application (unnecessary) creates
>a tighter coupling between them.
You have to couple the application to the DBMS somewhere, and the
right place is the external database view.
There is not any need to create a crippling procedural interface to
hide the external database view, which is a 4GL interface.
It is a lot of work to get something a lot worse than what you had.
Regards
Thomas Gagne
Because business rules change. A column that was stored is discovered
to be the sum of two other columns. It isn't only renamed--it's
removed. To maintain the interface the new columns are returned in the
projection (for new clients) and the old column becomes the addition of
the two.
A query that worked when the system was small no longer works and must
be reimplemented using a middle tier, or the query must be redirected to
another database server with denormalized tables, or a cube, or a ..
Another example is moving a column from one table into a new table. If
the application were using SQL to select the the column it must now know
to join the new table. Bad dependency.
Every application/DB interaction is a transaction and 75% of those are
inquiries. Transactions have rules, permissions, auditing, and
priorities. These things are better managed through procedures than
allowing the SQL (and hence the business rules) to escape into a client
application. When front-ended by a business-rule tier even more
flexibility is achieved.
frebe
If business rules change, your application will change too. This is not
an isolated database change.
> A column that was stored is discovered
> to be the sum of two other columns. It isn't only renamed--it's
> removed. To maintain the interface the new columns are returned in
the
> projection (for new clients) and the old column becomes the addition
of
> the two.
I am not sure I understand your example, but like you say, it is not a
renaming, you change the business logic. But the problem could easily
be solved by creating a new view with the same name and columns as the
old table. The modified table should be renamed. No (schema) interfaces
need to be broken in this case.
> A query that worked when the system was small no longer works and
must
> be reimplemented using a middle tier, or the query must be redirected
to
> another database server with denormalized tables, or a cube, or a ..
If you need to denormalize tables, you can still create views with the
old structure.
> Another example is moving a column from one table into a new table.
Why? Wouldn't this affect the rest of your application too?
> Transactions have rules, permissions, auditing, and
> priorities. These things are better managed through procedures than
> allowing the SQL
Permissions are best managed by the security system in the DBMS. I
agree that most DBMS don't have enough possibilities to validate data
(in a standardized way). This problem is best solved by a
table-oriented framework that adds extra validation on top of the DBMS.
For example, a validator could be registered to a table, to be executed
every time a record is inserted or updated into this table.
Fredrik Bertilsson
http://butler.sourceforge.net
Robert C. Martin
<danielaparker@spam?nothanks.windupbird.com> wrote:
>"Robert C. Martin" <uncl...@objectmentor.com> wrote in message
>news:perc21dsdinim56lh...@4ax.com...
>> On 2 Mar 2005 07:29:09 -0800, "frebe" <fredrik_b...@passagen.se>
>> wrote:
>>
>>>If you had a customer class with a property 'address', would you rename
>>>it to 'mailing-address' and break backward compatibility just because
>>>it is "sloppy" not to do it?
>>
>> Yes, wouldn't you? This is a two click operation in my IDE of choice.
<<snip>>
>But if you have external users, you have to be careful. One way is not to
>change old interfaces, add new ones instead. Migrate all users to the new
>ones if the names are that important, if the customer approves, if you can
>justify the cost.
You and I both know that many systems accumulate cruft because people
make "expedient" decisions. Instead of renaming a field, they add a
new field and allow the old field to ride along like non-coding
sequences of DNA.
I agree that there are times when you can't simply pull the rug out
from under users. However, in those cases you need to follow a
process of deprecation, so that you can keep ahead of the cruft.
>A database schema, or as much of it as the DBA wants to expose, represents
>an interface, not physical storage. The same issues apply to it as apply to
>any other interfaces, including the interfaces to your business objects.
>
>I agree with frebe, it sounds like your DBA doesn't know what he's doing.
The folks I'm consulting for have to make some significant database
changes. They are using hibernate to "encapsulate" the database.
Every schema change forces changes to the hibernate classes which
force changes to the code, which breaks lots of old tests.
The DBAs might be able to do things better, but they don't really have
a choice about changing the database. The changes need to be made.
The architects of the software chose tools and procedures that make
their code and tests hideously sensitive to the schema.
Robert C. Martin
wrote:
>Robert C. Martin wrote:
>> >If you had a customer class with a property 'address', would you
>rename
>> >it to 'mailing-address' and break backward compatibility just
>because
>> >it is "sloppy" not to do it?
>> Yes, wouldn't you? This is a two click operation in my IDE of
>choice.
>
>Breaking interfaces is a very bad behaivor in software engineering.
The accumulation of cruft is worse.
>It
>is not a two-click operation, you need to change every call of this
>property in the rest of the application.
Actually, it is. I happen to use a reasonably intelligent IDE. I can
make global changes to names with two clicks. (Maybe three).
>I am very surprised to have
>this answer from you. One of the best thing with OO is the concept of
>interfaces. But if you break the interface, the advantage is gone.
We use interfaces because they don't change as often as concrete code.
We don't demand that interfaces never change. Indeed, it is better to
change the interfaces than to allow nasty cruft to accumulate.
If you have a large user community, then you have to be careful about
how you change interfaces. You can't just change them without
notification. So you follow a rigorous process of deprecation. You
warn the users that a particular element is deprecated, and will not
be present in an upcoming release. Then you remove it at the
appointed time.
>I don't really understand why you need to change the name of 'address'
>at all. The semantics of the column was the same before and after the
>addition of the new column.
The name is wrong. It is no longer a universal address, it has become
just the mailing address.
>The fact that you added another column
>doesn't change the meaning of the first.
To paraphrase Martin Fowler, "Any idiot can write code that a machine
can understand. It takes skill and diligence to write code that a
human can understand."
>How could you accept a DBA that changes the schema in a non backward
>compatible way?
I don't want cruft. I want the DBAs to be diligent about keeping the
schema clean. I *never* want to be in the position of being afraid to
delete a column because I don't know what it is used for.
Robert C. Martin
wrote:
>I could also say like this: Using the right tool, a rename of a
>database column is a "two-click operation".
That's how it should be.
Robert C. Martin
wrote:
>I thought that not breaking interfaces, was something teached in every
>basic OO course.
No, it's only taught in the bad ones. It is far more important to
keep interfaces clean, than to keep them backwards compatible. You
may have to give users warning that a change is coming. If so, you
can use a deprecation scheme. What you should never do is allow old
cruft to build up indefinitely.
frebe
> The folks I'm consulting for have to make some significant database
> changes.
with the changes if the rest of the application should not be changed
too?
> They are using hibernate to "encapsulate" the database.
> Every schema change forces changes to the hibernate classes which
> force changes to the code, which breaks lots of old tests.
What are the purpose with significant database changes if they should
not affect the rest of the application, and the test scenarios. If you
change your business logic, your test scenarios need to be changed too.
If you do interface changes in your object model, doesn't you need to
rewrite some of your tests too?
> The DBAs might be able to do things better, but they don't really
have
> a choice about changing the database. The changes need to be made.
Please give some example.
Fredrik Bertilsson
http://butler.sourceforge.net
frebe
> keep interfaces clean
But in the same time you are complaining about the consequences of such
changes.
Fredrik Bertilsson
http://butler.sourceforge.net
frebe
>The accumulation of cruft is worse.
Ok, if you want to break your code, do it, but clean the mess up by
yourself. Don't force other to make unnecessary layers of abstraction
just becase you want to play around.
> The name is wrong. It is no longer a universal address, it has
become
> just the mailing address.
If the name was correct before the change, and the change does not
affect the semantics of the column, the name is still correct.
> I *never* want to be in the position of being afraid to
> delete a column because I don't know what it is used for.
Deleting a column (or method) is always dangerous and should only be
done with great care.
Fredrik Bertilsson
http://butler.sourceforge.net
Robert C. Martin
<danielaparker@spam?nothanks.windupbird.com> wrote:
>"Ilja Preuß" <pre...@disy.net> wrote in message
>news:d06f39$b7n$1...@stu1id2.ip.tesion.net...
>> frebe wrote:
>>
>>> Breaking interfaces is a very bad behaivor in software engineering. It
>>> is not a two-click operation, you need to change every call of this
>>> property in the rest of the application.
>>
>> Which *is* a two-click operation in modern IDEs.
>>
>Same issue for the Sun developer contemplating removing the addElement
>method from Vector.
Not really. Sun (or whomever) has hundreds of thousands of users.
Their deprecation process is correspondingly long. (Personally, I
think they should be a bit more aggressive.) The fewer the users, the
shorter the deprecation process should be. Inside even a very large
company I would think three months would be plenty. Inside a single
large IT department, a couple of weeks ought to be sufficient. For
smaller groups, I think deprecation can be replaced by continuous
integration.
Robert C. Martin
<danielaparker@spam?nothanks.windupbird.com> wrote:
>Your customer probably doesn't care. You care, but your customer doesn't
>care about you. Try writing "change column names" on one of your little
>cards, and see where that card ends up in the pile.
Ask my customer if he cares whether I use professional practices to
keep the quality of his software high.
A change of the kind we are talking about would simply be made as part
of normal daily practice. No card would need to be written. The
customer would never know about it. Nor should he. It's simply a
matter of good professional behavior.
Daniel Parker
Robert C. Martin wrote:
> fOn Wed, 2 Mar 2005 18:44:23 -0800, "Daniel Parker"
>
> changes. They are using hibernate to "encapsulate" the database.
> Every schema change forces changes to the hibernate classes which
> force changes to the code, which breaks lots of old tests.
Then it sounds like hibernate has serious shortcomings, since it seems
to me that a big point of encapsulating database access is to insulate
from database schema changes. Good encapsulation layers have that
property. I'd be interested in your comments: What is it about
hibernate that forces code changes? Does it bind Java classes to
tables? Or are they using hibernate inappropriately?
>
> The DBAs might be able to do things better, but they don't really
have
> a choice about changing the database. The changes need to be made.
> The architects of the software chose tools and procedures that make
> their code and tests hideously sensitive to the schema.
The way that you've described it, it sounds like the DBA is doing the
equivalent of breaking the build. That's not good, it shouldn't
happen, you don't want developers breaking the build. If people change
the database schema, they need to manage that change, make sure that
everything that depends on those changes also changes. But you already
know that :-)
Regards,
Daniel Parker
Shayne Wissler
> On Wed, 2 Mar 2005 20:29:52 -0800, "Daniel Parker"
> <danielaparker@spam?nothanks.windupbird.com> wrote:
>
>>Your customer probably doesn't care. You care, but your customer doesn't
>>care about you. Try writing "change column names" on one of your little
>>cards, and see where that card ends up in the pile.
>
> Ask my customer if he cares whether I use professional practices to
> keep the quality of his software high.
>
> A change of the kind we are talking about would simply be made as part
> of normal daily practice. No card would need to be written. The
> customer would never know about it. Nor should he. It's simply a
> matter of good professional behavior.
I have never agreed with you more than in your last set of posts along these
lines. So much about the software industry would be improved if more people
followed your advice here.
The existence of legacy users represents an obligation that we improve the
code methodically; it's not an excuse for not improving it or for
perpetually carrying around "cruft".
Shayne Wissler
http://www.thoughtsonsoftware.com
Andrew McDonagh
Agreed!
frebe
> keep the quality of his software high.
One an application has entered production mode, every change has to be
tested very carefully, because every change is a possible way to
introduce a new bug. Changing more than necessary will not keep the
quility of the software high. Breaking interfaces is a will most likely
decrease software quality.
> A change of the kind we are talking about would simply be made as
part
> of normal daily practice
Ask any IT-manager: "I want to rename a method because I don't like
the name. I will do with two mouse-clicks, BUT we will have to rebuild
and redeploy the entire application." What do you think the answer will
be?
Fredrik Bertilsson
http://butler.sourceforge.net
frebe
> followed your advice here.
For companies developing and maintaining applications, version
management is a very difficult task. If you have a team developing
components that are collaborating, you will have broken builds all the
time, if you are not careful with interface changes. There are
established techonologies like deprecation for handling this problem.
If you have a one-memeber project, this is not a problem, but as soon
as multiple developers working together the problem will come.
Do you have some motivation how software industry could be improved by
breaking interfaces more?
Fredrik Bertilsson
http://butler.sourceforge.net
Shayne Wissler
"frebe" <fredrik_b...@passagen.se> wrote in message
news:1109879465.8...@l41g2000cwc.googlegroups.com...
Developers who code like you're saying they should really end up writing 2+
modules for every one: the first to do what it needs to do, the second to
adapt it to what the external modules have been written to expect. Software
becomes a bloated pile of adapter functions that "hide the implementation
details", and half the time all you end up doing is cranking out these
pointless adapter functions.
Furthermore the way you frame this implies that you just don't care to
understand. Who is going to argue that software is improved by breaking it?
No one.
You're missing the point here: software is improved by simplifying it while
maintaining the same features. Do more with less. Sometimes that means you
break something and have to fix it. That's part of the cost of improvement.
Shayne Wissler
http://www.thoughtsonsoftware.com
Robert C. Martin
wrote:
>Robert C. Martin wrote:
>> The folks I'm consulting for have to make some significant database
>> changes.
>Why did the have to? What types of changes is it? What are the purpose
>with the changes if the rest of the application should not be changed
>too?
The rest of the application does have to change. Unfortunately the
changes to the schema force many more changes than they should. The
software is very dependent on the schema. So a small change to the
schema can have significant repercussions on the source code.
>What are the purpose with significant database changes if they should
>not affect the rest of the application, and the test scenarios.
They should and do affect parts of the application and tests.
Unfortunately, the way the software is structured, the schema changes
affect far more than they out to.
>If you
>change your business logic, your test scenarios need to be changed too.
Certainly. The goal is to make sure that those changes have minimum
impact. The designers in this case failed.
>If you do interface changes in your object model, doesn't you need to
>rewrite some of your tests too?
Certainly. Again, it is a matter of degree.
Robert C. Martin
<daniel...@hotmail.com> wrote:
>
>Robert C. Martin wrote:
>> fOn Wed, 2 Mar 2005 18:44:23 -0800, "Daniel Parker"
>>
>> The folks I'm consulting for have to make some significant database
>> changes. They are using hibernate to "encapsulate" the database.
>> Every schema change forces changes to the hibernate classes which
>> force changes to the code, which breaks lots of old tests.
>
>Then it sounds like hibernate has serious shortcomings, since it seems
>to me that a big point of encapsulating database access is to insulate
>from database schema changes.
I don't know if this is a hibernate issue, or just an issue with the
way they've used it. What I know (second hand) is that when they make
a schema change, the cost of the source code change is high.
>Good encapsulation layers have that
>property.
Agreed.
>> The DBAs might be able to do things better, but they don't really
>have
>> a choice about changing the database. The changes need to be made.
>> The architects of the software chose tools and procedures that make
>> their code and tests hideously sensitive to the schema.
>The way that you've described it, it sounds like the DBA is doing the
>equivalent of breaking the build. That's not good, it shouldn't
>happen, you don't want developers breaking the build. If people change
>the database schema, they need to manage that change, make sure that
>everything that depends on those changes also changes. But you already
>know that :-)
Indeed! One problem there is that the DBAs apparently don't
coordinate with the developers. They make changes as and when they
feel they are necessary, and let the developers deal with the fallout.
Alfredo Novoa
<daniel...@hotmail.com> wrote:
>> The folks I'm consulting for have to make some significant database
>> changes. They are using hibernate to "encapsulate" the database.
>> Every schema change forces changes to the hibernate classes which
>> force changes to the code, which breaks lots of old tests.
>
>Then it sounds like hibernate has serious shortcomings, since it seems
>to me that a big point of encapsulating database access is to insulate
>from database schema changes. Good encapsulation layers have that
>property.
Hibernate is a technological aberration. It is a layer that converts a
4GL interface into a primitive procedural pointer based interface.
http://www.hibernate.org/hib_docs/reference/en/html/example-weblog.html#example-weblog-code
This is like to put an sports car on the top of a mule chariot.
A well designed set of views is the encapsulation layer that the
application needs.
Regards
Daniel Parker
>
> One problem there is that the DBAs apparently don't
> coordinate with the developers. They make changes as and when they
> feel they are necessary, and let the developers deal with the
fallout.
>
agile sympathies, it shouldn't come as too much of a shock to them if
you propose making the DBA's part of the development team, have them
make the DB schema changes first in their local environment, require
them to do a search on the hibernate classes for dependencies on the
database schema, fix them, do a build, make sure that it builds clean
or if it doesn't, fix it, and don't apply the database changes in dev
till everything builds clean. It'll be good for the DBA's, they'll get
to do something new, and everybody should be happier. Heck, this may
even be one of those rare occaisons when pairing makes sense.
Regards,
Daniel Parker
Robert C. Martin
wrote:
>> No, it's only taught in the bad ones. It is far more important to
>> keep interfaces clean
>
>But in the same time you are complaining about the consequences of such
>changes.
I'm complaining about architectures that are sensitive to such
changes. There's a big difference.
Robert C. Martin
wrote:
>>>Breaking interfaces is a very bad behaivor in software engineering.
>>The accumulation of cruft is worse.
>
>Ok, if you want to break your code, do it, but clean the mess up by
>yourself. Don't force other to make unnecessary layers of abstraction
>just becase you want to play around.
Keeping systems clean is not "playing around". It is a necessary
activity that is adopted by professionals. As a professional, I
expect other professionals to:
1. Keep their systems clean.
2. Insulate their systems from external changes.
If they can't or won't do that, then they should find some other kind
of career.
>> The name is wrong. It is no longer a universal address, it has
>become
>> just the mailing address.
>
>If the name was correct before the change, and the change does not
>affect the semantics of the column, the name is still correct.
The change, in this case, *does* affect the semantics of the column.
Prior to the change 'address' was used for all mail contact. After
the change it is used for all non-billing related mail contact.
The introduction of a new field can modify the semantics of old fields
simply by existing. Those old fields may need to be renamed so that
their names match their newly refined semantics.
>
>> I *never* want to be in the position of being afraid to
>> delete a column because I don't know what it is used for.
>Deleting a column (or method) is always dangerous and should only be
>done with great care.
True. But it should also be done. Avoiding something because it
requires care is sloppy.
Robert C. Martin
wrote:
>> Ask my customer if he cares whether I use professional practices to
>> keep the quality of his software high.
>
>One an application has entered production mode, every change has to be
>tested very carefully, because every change is a possible way to
>introduce a new bug. Changing more than necessary will not keep the
>quility of the software high. Breaking interfaces is a will most likely
>decrease software quality.
I maintain quality by keeping a bastion of unit tests, and acceptance
tests constantly running. No one is allowed to check in code that
breaks any of these tests. The tests provide coverage over every
module, every class, and every method. They don't catch all bugs, but
very few bugs get through.
Messy code is a source of bugs. The more tangled the code the more it
breaks in strange ways when you make apparently simple changes.
Keeping code clean is one way of avoiding this.
>> A change of the kind we are talking about would simply be made as
>part
>> of normal daily practice
>
>Ask any IT-manager: "I want to rename a method because I don't like
>the name. I will do with two mouse-clicks, BUT we will have to rebuild
>and redeploy the entire application." What do you think the answer will
>be?
Most method renamings shouldn't bother him. A few might be in
components that other folks make use of. In that case I'll need to
notify them of the change, and possibly use a deprecation scheme. The
IT manager will know I'm doing that, because he knows he hired a
professional. So, in fact, I won't ask him. It's not the kind of
detail he should have to deal with.
Daniel Parker
frebe wrote:
> > Ask my customer if he cares whether I use professional practices to
> > keep the quality of his software high.
That's good, professional practices, I like that.
>
> Ask any IT-manager: "I want to rename a method because I don't like
> the name. I will do with two mouse-clicks, BUT we will have to
rebuild
> and redeploy the entire application." What do you think the answer
will
> be?
>
Of course, but that's why we do it surreptiously, without asking, and
slip it in with something else.
Daniel
Robert C. Martin
<daniel...@hotmail.com> wrote:
Let's be clear. This is not some way to sneak changes into the source
code without the customer or manager knowing. I'm not in to trickery
or skulking.
Keeping the code clean is simply good professional behavior. If a
manager or customer saw me doing it and asked me to explain, I would
tell them that this is a necessary part of software development. If
he then told me to cease and desist, I would explain that these
practices keep me going fast, and to stop using them would slow me,
and everyone else who has to deal with my code, down. In the end, if
my explanations did not suffice, and he insisted that I cease and
desist, I would refuse. He may fire me if he wishes, but he cannot
force me into unprofessionalism.
Daniel Parker
>
> Sun (or whomever) has hundreds of thousands of users.
> shorter the deprecation process should be. Inside even a very large
> company I would think three months would be plenty. Inside a single
> large IT department, a couple of weeks ought to be sufficient. For
> smaller groups, I think deprecation can be replaced by continuous
> integration.
>
relevent cost is the cost of introducing change to the affected users, which
ranges from large to small, depending on the numbers, geographical
distribution, organizational structure, etc.
Regards,
Daniel Parker
Daniel Parker
>
> Let's be clear. This is not some way to sneak changes into the source
> code without the customer or manager knowing. I'm not in to trickery
> or skulking.
>
> Keeping the code clean is simply good professional behavior. If a
> manager or customer saw me doing it and asked me to explain, I would
> tell them that this is a necessary part of software development. If
> he then told me to cease and desist, I would explain that these
> practices keep me going fast, and to stop using them would slow me,
> and everyone else who has to deal with my code, down. In the end, if
> my explanations did not suffice, and he insisted that I cease and
> desist, I would refuse. He may fire me if he wishes, but he cannot
> force me into unprofessionalism.
Consider the following scenario. You don't like the name of a table column,
so you decide to change it. It turns out that there are quite a few
implications to that change, and a customer who happens to notice tells you
that it's your decision, but asks you to take into consideration her worry
that the change could impact a critical production deployment happening over
the weekend. What would you do? I don't think I have to ask you, I think I
know what you would do, even if you thought you could get it in.
Many of these kinds of changes have aesthetic value, but not a lot of
business value. We do them anyway, because aesthetics matter to us, and
also because names matter to us, they help us think about the system. But
there's a cost to these changes, and good professional behaviour requires
that we weigh the cost, as well as the likelihood of causing distress and
worry in our customers.
Regards,
Daniel Parker
Shayne Wissler
"Daniel Parker" <danielaparker@spam?nothanks.windupbird.com> wrote in
message news:nqPVd.40969$kz6.7...@news20.bellglobal.com...
> Consider the following scenario. You don't like the name of a table
> column, so you decide to change it. It turns out that there are quite a
> few implications to that change, and a customer who happens to notice
> tells you that it's your decision, but asks you to take into consideration
> her worry that the change could impact a critical production deployment
> happening over the weekend. What would you do? I don't think I have to
> ask you, I think I know what you would do, even if you thought you could
> get it in.
>
> Many of these kinds of changes have aesthetic value, but not a lot of
> business value. We do them anyway, because aesthetics matter to us, and
> also because names matter to us, they help us think about the system. But
> there's a cost to these changes, and good professional behaviour requires
> that we weigh the cost, as well as the likelihood of causing distress and
> worry in our customers.
Usually a project has points where these kinds of things can be dealt with
as a batch. For example if you were doing a major release with other changes
that needed good regression testing it wouldn't be that much extra cost to
throw in this change too. So I'd just save the problem for one of those
points.
I'd also add that it's not merely aesthetics, and if you put it that way
you're asking for trouble from your customer. If it speeds up your thinking,
it's more than aesthetics, it's a matter of engineering efficiency. If it's
really only aesthetics, then I'd say don't make the change, no business can
justify a programmer writing code just because he's fond of the way it
looks; on the contrary, a programmer writing code that way should be fired.
Shayne Wissler
http://www.thoughtsonsoftware.com
topmind
and some interpret it in such a way as to make a big mess. Mix that
with the HTML+DOM crap we are forced to use for *cough* GUI's in biz
apps.
-T-
topmind
impact the code of a message queue adapter. *)
Message queue adapters are usually already API's, so one couldn't mix
them without really going out of their way. How about we stick to UI
and DB for now because these are the most contentious.
(* If it turns out that a future change requires a different
refactoring, that is a good indication that the design needs more
thought. *)
It is hard to predict the kinds of changes that have yet to happen.
Anyhow, this is apparently turning into an XP issue, which I don't want
to get into.
(* Will you be substantiating these assertions or retracting them? *)
Let me reworded it as a question: Where is the impericle evidence that
separating them is net beneficial?
(* I'm not aware of a methodology that encourages the tight coupling
of application and business logic. What methodology do you use? *)
See:
http://www.c2.com/cgi/wiki?ProceduralMethodologies
(* What forms of indirection do you find to be so expensive that they
should be avoided? *)
Almost any indirection that is not there to solve repetition issues is
suspect. Such usually results in more code and more interfaces that
have to change. Changes will often require changing both the
implementation and the interface, thus *double* the work. The extra
code is certain while the changes that we are allegedly protecting code
from tend to have fractional probabilities, and probably relatively low
ones.
-T-
Daniel Parker
news:prOdndxMIqq...@comcast.com...
>
> I'd also add that it's not merely aesthetics, and if you put it that way
> you're asking for trouble from your customer. If it speeds up your
> thinking, it's more than aesthetics, it's a matter of engineering
> efficiency. If it's really only aesthetics, then I'd say don't make the
> change, no business can justify a programmer writing code just because
> he's fond of the way it looks; on the contrary, a programmer writing code
> that way should be fired.
>
everybody else, why would you care if he wants to make his code beautiful in
a way that adds no business value?
-- Daniel