Re: Relational-to-OOP Tax
- From: "frebe" <frebe73@xxxxxxxxx>
- Date: 24 Feb 2007 02:20:39 -0800
that SQL is the only necessary language. Are you
seriously claiming
that there is no need for other languages?
SQL is the best availible language for data management. Other
languages are better for other tasks.
It can also be re-used without exposing the database schema
throughout the application.
And the benefits with that are....?
Schemas change for different reasons than
application code.
So far, nobody at comp.object have proved this.
Decoupling in a general sense have many Decoupling >> has also aWhat are the exact costs you are so concerned
cost and that cost has to be compared to the benefits.
with?
1. Code bloat (which I have already proved).
2. Bad performance. Because the code bloat, programmers avoid writing
new functions and tries to reuse existing functions that doesn't
really fit.
3. Readability. It is harder to read the source code if you have to
step through multiple layers while finding out what the application
actually do. This is acceptable for functions that are called from
multiple points, but only a disadvantage if the function is called
only once.
4. Quality. Changning a function because of the needs of one caller,
might make it fail for another caller. This problem does indeed exists
as soon as you use functions, but it is increased by the fact that
reuse is forced when it doesn't really fit.
The benefits
in terms of non-functional requirements alone are quite
significant.
This is still not proved.
Both horizontal and vertical scalability benefit from theWhat is a well-encapsulated component in this case?
existence
of decoupled, well-encapsulated components.
Are you talking
about EJB beans or something here?
Goddess no. I consider EJBs to be the antithesis of a
well-encapsulated component.
Ok, so what kind of components which would increate scalability, are
you talkning about?
In this case I'm thinking of
fine-grained services that can be aggregated into coarser grained
services. Consider the case of an order management system that
consists of a workflow that accesses multiple applications (CRM,
billing, MRP/ERP, etc.). Each activity is a coarse grained service
that uses multiple, shared fine-grained services. Scalability can be
achieved both through distributing the services and by running
mulitple instances of any that are particularly heavily used.
What service mechanism are you talkning about? COM+, Web Services,
Corba? Does this also means that the SQL statements doesn't only have
to be separated into special classes, functions but also into separate
components of some kind? Another code bloat I assume? Imagine, every
time you need a new select statement, you need to add a method but
also change interface definition files etc.
Security is easier to implement and prove when components have
single responsibilities.
Do you have some examples of this?
One of the primary difficulties with implementing security
correctly is the difficult to understand interactions between
complex components. Having a single responsibility for each
component simplifies analysis and testing considerably.
Is this an example?
It's a description of the issue sufficient for anyone familiar
with implementing security models to understand my point. That makes
it far more supportive of my statement than anything you have yet
produced.
In other words: You are not able to produce one single example.
/Fredrik
.
- Follow-Ups:
- Re: Relational-to-OOP Tax
- From: Jerry Coffin
- Re: Relational-to-OOP Tax
- From: Patrick May
- Re: Relational-to-OOP Tax
- References:
- Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- From: topmind
- Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- From: Patrick May
- Relational-to-OOP Tax (was: Critique of Robert C. Martin's...)
- From: topmind
- Re: Relational-to-OOP Tax (was: Critique of Robert C. Martin's...)
- From: Patrick May
- Re: Relational-to-OOP Tax (was: Critique of Robert C. Martin's...)
- From: topmind
- Re: Relational-to-OOP Tax
- From: Patrick May
- Re: Relational-to-OOP Tax
- From: topmind
- Re: Relational-to-OOP Tax
- From: Patrick May
- Re: Relational-to-OOP Tax
- From: topmind
- Re: Relational-to-OOP Tax
- From: Patrick May
- Re: Relational-to-OOP Tax
- From: topmind
- Re: Relational-to-OOP Tax
- From: Patrick May
- Re: Relational-to-OOP Tax
- From: frebe
- Re: Relational-to-OOP Tax
- From: Patrick May
- Re: Relational-to-OOP Tax
- From: frebe
- Re: Relational-to-OOP Tax
- From: Patrick May
- Re: Relational-to-OOP Tax
- From: frebe
- Re: Relational-to-OOP Tax
- From: Patrick May
- Re: Relational-to-OOP Tax
- From: frebe
- Re: Relational-to-OOP Tax
- From: Patrick May
- Re: Critique of Robert C. Martin's "Agile Principles, Patterns, and Practices"
- Prev by Date: Re: Relational-to-OOP Tax
- Next by Date: Re: Relational-to-OOP Tax
- Previous by thread: Re: Relational-to-OOP Tax
- Next by thread: Re: Relational-to-OOP Tax
- Index(es):
Relevant Pages
|