Single object or multiple objects per busines object

[lastcraft]

Hi...

Damn is it spooky reading all the threads lately about you guys talking about Dependency Injection,TypeSafe PHP and now Hibernate...

I did a quick SitePoint search and the topics have actually been regulars for some time. Here are the hits: AOP 22, Hibernate 44, Dependency Injection 7.

I asked Josh Einhorn about XDoclet support when he was in London recently, but it looks like the internals of PHPDoc need some serious internal work before that can be tackled.

yours, Marcus

[Tony Marston]

I have very high levels of reusability, and have reused the same code in several applications, therefore my levels of coupling and dependency must be low enough.

This is just bad logic. Take the following:

    Dogs have legs
    I have legs
    I am a dog

Doesn't make much sense. It is an incorrect connection of the first two truths that result in the third statement which is an obvious fallicy. (well, some may think I am a dog, but that's a topic for another thread.)

    Decoupled code is reusable
    My code is reusable
    My code is decoupled

Same kind of logic. I do agree that your code is probably decoupled. However I honestly don't think your code is as highly decoupled as it could be. That's all I'm saying. Again is it wrong? No, it's just how you do it.

Your example does not have any merit. It is a typical example of the woolly thinking that I have come to expect from certain people in this forum.

Using these definitions of Coupling and Cohesion and Visibility and Dependency I come up with the following:

• High cohesion will maximise reusability, low cohesion will prevent it.
• Low coupling will maximise reusability, high coupling will prevent it.
• Low dependency will maximise reusability, high dependency will prevent it.

As the levels of reusability in my infrastrucure are very high it must mean that the levels of cohesion, coupling and dependency are more than adequate. Any *problems* that you keep attempting to identify are not real problems at all. They are unreal, academic, hypothetical and unworthy of serious consideration.

I don't know that your view on dependancy is entirely accurate. It may not seem like your controller is depending on SQL because it's not using full fledged SQL statements. However, let me ask you this. If you take a controller that is providing SQL fragments, and you decide you want to change the underlying database to a data system that doesn't use SQL will you have to make changes to your controller? If the answer is yes then that means your controller is dependent on SQL.

This situation will not happen in reality, therefore it is purely academic and hypothetical and can be ignored. I can absolutely guarantee that I will never be involved in a project that will take an existing application which uses an SQL database and port it to a non-SQL database.

I may be involved in creating a new application (or individual components within an application) that use a non-SQL data source, but that is a different scenario altogether. The one that you (and your cohorts) keep suggesting just will not happen.

Now you may say "I won't ever change away from SQL." That isn't the point, I am just saying your code is dependant on SQL. I am not even really saying that it's bad to depend on SQL in your controller. I am just saying it's not 3-tiered.

All the descriptions of the 3-tier architecture I have seen simply state that you should be able to switch to a different database by switching a single component. It is implied in this statement that you are making the switch between equivalent database systems (e.g. from one SQL database to another SQL database). I have never seen in any description that this should include he ability to switch between incompatible database sytems.

Does any other database abstraction layer (such as PEAR) provide this ability?

I design and build web applications that use an SQL database (any SQL database) as their primary data source. I have optimised my infrastructure with those "limitations" in mind.

Q1: What percentage of today's web applications use a non-SQL data source?

Q2: What percentage of today's web applications are likely to be ported from an SQL database to a non-SQL data source?

Unless you can produce figures to show that it will be worthwhile to cater for this eventuality I will continue to treat the possibility as unworthy of serious consideration. I do not see this hypothetical possibility as an absolute requirement of any description I have read on the 3-tier architecture, therefore I do not consider that my implementation is *broken*. It fits the generally accepted view that exists in the *real* world, not the hypothetical view that exists in cloud-cuckoo land.

[Tony Marston]

If thats good enough for you, thats good enough for me. Im not going to argue with that except to quote the same page about 2 paragraphs up.

#4 Data access tier: [e.g server running JDBC] all data I/O to data repositories handled here for example connects to database, fetches data from various sources including files, XML documents, spread sheets and so on.
#5 Data tier: [e.g a database] application data is stored here in repositories - perhaps a database, perhaps text files, perhaps even an XML database like the Apache Groups XIndice

Yes, but although you may have DAOs for each of those different file systems it does not demand that all the file systems be interchangeble. It does not say, for example, that you should be able to take an existing application written with an SQL database as its primary data source and switch it to say, a CSV file system, just by switching a single component. My understanding is that you should be able to switch between compatible file systems, such as from one SQL database to another SQL database, so your idea that I must cater for the possibility of porting an existing application from one file system to a totally incompatible file system is unrealistic. It just will not happen in the *real* world, therefore your claim that this lack of ability causes a problem just does not have any basis in fact. It is not a problem in the *real* world, so I see no reason to waste my time in implementing a solution.

That is why I class myself as a *pragmatic* programmer instead of a *dogmatic* one. I do what is necessary to achieve results, and I do not waste my time on hypothetical or academic scenarios.

[Tony Marston]

I made the decision two years ago to stick to standard SQL as much as possible, and not to make use of features that were unique to a particular DBMS (such as MySQL's auto-increment feature). I balance any possible losses by the gains of having applications that can be deployed on any popular DBMS.

This is something I disagree on, although i might be alone in this. I'd rather use DB specific code and have it run smoothly and efficiently than limit myself to the standards.

If you wish to build an application that is tied to a particular DBMS, then that is your choice. My aim was to build applications that could be used by several customers using the DBMS of their choice. If a potential customer asks for a copy of one of my applications and wants to know if it will run on databaseY, which one of then following answers would impress him the most?

• This application will run on a variety of different relational databases at the flick of a single switch.
• This application has been built around the features of databaseX, so if you want it ported to databaseY it will cost you a chunk of money and delay the implementation date.

Answers on a postcard to ......

If I were to switch DB's, I'd just use a seperate set of DAO's and take advantage of that DB's features.

By sticking to standard SQL I am not losing anything of significance. It does, however, give me the ability to switch from one DBMS to another simply by changing a single component.

My implementation is balanced in favour of my requirements, while your implementation is balanced in favour of your requirements. They are different because they are designed around different requirements. Neither is *wrong* unless you can point to something and say "this does not meet the stated requirements".

[mjlivelyjr]

You seem to be living under the assumption that technology never changes. I will agree with you when you say that SQL will likely never change. The core of SQL will probably stay the same until the end of eternity. However, there is no way that you can garuntee that RDBMS will remain the dominant persistance system. Technology's tendency is to always progress. People have already seen that there are significant problems with using RDBMSs in Object Oriented programming, that's why you see so many systems like Hibernate, Torque, Etc. There is an impedance issue with relational and object data that is not very easy to overcome. It's honestly only a matter of time before somebody comes up with some technology that will eventually replace RDBMS. It may take months, it may take years. If you refuse to acknowledge that then there is really no point in discussing this further.

You have admitted that your application relies on SQL for data persistance. You then continue to say your application is loosely layered. I see now that you have slightly changed your tone and are now saying it's layered "loosely enough" so I guess in a way I have gotten my point accross.

All the descriptions of the 3-tier architecture I have seen simply state that you should be able to switch to a different database by switching a single component. It is implied in this statement that you are making the switch between equivalent database systems (e.g. from one SQL database to another SQL database). I have never seen in any description that this should include he ability to switch between incompatible database sytems.

Does any other database abstraction layer (such as PEAR) provide this ability?

Then you are reading extremely watered down views of n-tier architecture that are most likely being conviewed in a tutorial for people new to the concept. I would wager to guess that the authors themselves would even agree with this assesment.

I am going to go ahead and post two quotes they are both from HarryF's article and they both have actually been quoted already but I don't think tied together properly.

4. Data access tier: [e.g server running JDBC] all data I/O to data repositories handled here for example connects to database, fetches data from various sources including files, XML documents, spread sheets and so on.
5. Data tier: [e.g a database] application data is stored here in repositories - perhaps a database, perhaps text files, perhaps even an XML database like the Apache Groups XIndice

Each layer should be interchangeable. This results in some further rules;

* Each layer should have a clearly defined data interface (API: application program interface).
* Layers should expect nothing of other layers except that they use the defined APIs to exchange data.

The data access tier, for example, should not expect a particular database, such as Oracle, to reside below it. In other words it should be possible to replace Oracle with an alternative database without any impact on the data access tier (or any tiers above it).

Take a note at point 5 in the first quote. The data tier can be a database, a text file, an xml database, pretty much any existing persistance system. Now the second quote says each layer should be interchangeable. Well your data layer is only interchangeable in so much as you are using a data layer that supports SQL.

Also, in the true sense of a 3 tier architecture you honestly can't consider Pear:B or any other database abstraction layer to be the data tier in and of itself. It has to have a set of classes within the layer that can act as a buffer between the data tier and the domain tier or business logic tier. Otherwise, like in your architecture you are going to be tied to using only an SQL driven database.

Yes, but although you may have DAOs for each of those different file systems it does not demand that all the file systems be interchangeble. It does not say, for example, that you should be able to take an existing application written with an SQL database as its primary data source and switch it to say, a CSV file system, just by switching a single component. My understanding is that you should be able to switch between compatible file systems, such as from one SQL database to another SQL database, so your idea that I must cater for the possibility of porting an existing application from one file system to a totally incompatible file system is unrealistic. It just will not happen in the *real* world, therefore your claim that this lack of ability causes a problem just does not have any basis in fact. It is not a problem in the *real* world, so I see no reason to waste my time in implementing a solution.

Excellent use of confirmation bias...no where in HarryF's article does it say the only requirement for layer interchangibility is that you need only to change between compatibile file systems. The only way you can come to that conclusion based on HarryF's article is to read meaning into it. I recommend you find a more definitive source to quote from before you begin making such claims.

Unless you can produce figures to show that it will be worthwhile to cater for this eventuality I will continue to treat the possibility as unworthy of serious consideration. I do not see this hypothetical possibility as an absolute requirement of any description I have read on the 3-tier architecture, therefore I do not consider that my implementation is *broken*. It fits the generally accepted view that exists in the *real* world, not the hypothetical view that exists in cloud-cuckoo land.

I now understand why people think the way they do about your opinion. You continue to dismiss anybodies reservations about the flexibility with your solution as pure hypothesis and conjecture that has absolutely no real world value.

This wasn't a thread for people to showcase their architecture, it was a thread to give someone suggestions on how to do things. We were pointing out drawbacks to your architecture based on that very point. Just because you never think you will use anything other than SQL doesn't mean no one will ever use SQL. You basically started the entire argument by pointing out a drawback in someone else's architecture that was using a data mapper which an extremely valid, highly used, highly flexible, and highly successful method. Then you proceeded to act absolutely shocked and mortified when someone pointed out a drawback in your architecture and you have continued throughout the entire conversation without a single time acknowledging any drawback in your solution. Tell me, how is this helpful to those considering different styles of architecture?

Quite frankly all you had to do to avoid this argument was to say "My architecture may not be as loosely layered as yours but I made that design decision because....".

It fits the generally accepted view that exists in the *real* world, not the hypothetical view that exists in cloud-cuckoo land.

Well then Mr. Marston, let me step out of "cloud-cuckoo" land and tell you that your view of the *real* world appears to be jaded. Thank you for making it personal.

[Dr Livingston]

and others too, when I get the time to write the DAOs

Are you not forgetting something that'd need changing as well huh ? Doubtful you'd actually have any time at all to develop, when your wasting valuable time refactoring templates to hold your SQL in my view.

Btw, I now have you on my ignore list as well; a few other members have done just that

Goodbye.

[auricle]

I cannot point to any chapter and say "this says that what I am doing is valid", just as you cannot point to any chapter and say "this proves that what you are doing is invalid".

I wouldn't make such a claim. I don't own those books and I am not positing a methodology. I just thought it might be an easy way for you to establish a more credible argument. (It does seem that your credibility is at issue here and I would have thought you had an interest in establishing and maintaining it.)

If were make a claim and others disagreed I might look to such authoritative sources and quote them (with annotation and interpretation as I deemed appropriate) in support of my position. You have not done this. (Rant deflection: Note that I have said nothing about the relative merits of Tony's design decisions.)

[Tony Marston]

You seem to be living under the assumption that technology never changes. I will agree with you when you say that SQL will likely never change. The core of SQL will probably stay the same until the end of eternity. However, there is no way that you can guarantee that RDBMS will remain the dominant persistance system. Technology's tendency is to always progress. People have already seen that there are significant problems with using RDBMSs in Object Oriented programming, that's why you see so many systems like Hibernate, Torque, Etc. There is an impedance issue with relational and object data that is not very easy to overcome. It's honestly only a matter of time before somebody comes up with some technology that will eventually replace RDBMS. It may take months, it may take years. If you refuse to acknowledge that then there is really no point in discussing this further.

I have never said that technology will never change. All I said was that SQL-compliant databases are used in virtually all web applications, so I see no need in expending any effort to deal with non-SQL databases.

Some individuals may find fault with the current crop of RDBMS's and propose or even develop alternatives (such as an Object Oriented Data Base Management System), but would they be accepted without a standard SQL interface? There may be a market out there for non-SQL databases, but it is a niche market which does not cover web applications. It is so small that it is insignificant. That is why your complaint that my infrastructure is faulty because it will deal *only* with SQL databases is so very, very weak.

Even if someone were to come up with a "killer" DBMS which did not have an SQL interface, how long would it take to become a sigificant player in the market? I would think not months, nor even years, but decades.

All the descriptions of the 3-tier architecture I have seen simply state that you should be able to switch to a different database by switching a single component. It is implied in this statement that you are making the switch between equivalent database systems (e.g. from one SQL database to another SQL database). I have never seen in any description that this should include he ability to switch between incompatible database sytems.

Then you are reading extremely watered down views of n-tier architecture that are most likely being conviewed in a tutorial for people new to the concept. I would wager to guess that the authors themselves would even agree with this assesment.

I have googled for "3 tier architecture" and read countless documents each giving a slightly different description, with more or less detail. Without exception these documents state that the purpose of the data access tier is to provide the ability to switch an existing application from one database/RDBMS to another. There is not even the slightest hint that this should include to ability to switch from one file system to a totally incompatible file system.

I have assumed that the switch is limited to "one SQL database" to "another SQL database". I believe this is a common assumption as I have yet to hear of ANY infrastructure that will allow an existing application which was developed around an SQL database to be ported to a non-SQL file system.

You may think that my assumption is incorrect, but how many people would agree that your different assumption/interpretation is correct?

Here are some quotes from HarryF's article. They have actually been quoted already but I don't think tied together properly.

4. Data access tier: [e.g server running JDBC] all data I/O to data repositories handled here for example connects to database, fetches data from various sources including files, XML documents, spread sheets and so on.
5. Data tier: [e.g a database] application data is stored here in repositories - perhaps a database, perhaps text files, perhaps even an XML database like the Apache Groups XIndice

Each layer should be interchangeable. This results in some further rules;

* Each layer should have a clearly defined data interface (API: application program interface).
* Layers should expect nothing of other layers except that they use the defined APIs to exchange data.

The data access tier, for example, should not expect a particular database, such as Oracle, to reside below it. In other words it should be possible to replace Oracle with an alternative database without any impact on the data access tier (or any tiers above it).

Take a note at point 5 in the first quote. The data tier can be a database, a text file, an xml database, pretty much any existing persistance system. Now the second quote says each layer should be interchangeable. Well your data layer is only interchangeable in so much as you are using a data layer that supports SQL.

Where it says

it should be possible to replace Oracle with an alternative database without any impact on the data access tier (or any tiers above it)

I have interpretted this to mean an alternative database of equal ability which, to my mind, excludes switching between SQL and non-SQL databases. Apart from this thread I have yet to see any article which contradicts this assumption.

Does any other database abstraction layer (such as PEAR) provide this ability?

Also, in the true sense of a 3 tier architecture you honestly can't consider Pear:B or any other database abstraction layer to be the data tier in and of itself.

Why not? I have seen several packages being advertised as 3-tier when all they have is a templating system (usually Smarty) at the front end, a collection of classes built around certain design patterns in the middle, and a database abstraction layer such as PEAR or Creole at the back end. Are you going to complain that their implementation is totally invalid?

It has to have a set of classes within the layer that can act as a buffer between the data tier and the domain tier or business logic tier. Otherwise, like in your architecture you are going to be tied to using only an SQL driven database.

All the database abstraction layers I have ever seen will only provide the ability to switch from one SQL database to another SQL database. They do not see this as a significant limitation. I do not see it as a significant limitation. Why do you keep insisting otherwise?

Nowhere in HarryF's article does it say the only requirement for layer interchangibility is that you need only to change between compatibile file systems. The only way you can come to that conclusion based on HarryF's article is to read meaning into it. I recommend you find a more definitive source to quote from before you begin making such claims.

Nowhere does it say the opposite, either. You are reading the same article yet coming up with a different interpretation. What makes to think that your interpretation is valid? Can you quote any published documents which back up your interpretation?

I now understand why people think the way they do about your opinion. You continue to dismiss anybodies reservations about the flexibility with your solution as pure hypothesis and conjecture that has absolutely no real world value.

You seem to think that not providing the ability to switch between incompatible file systems is a serious limitation that needs to be addressed. I do not. It may be a "limitation" in your eyes, but it is so insignificant that I consider it to be unimportant and irrelevant.

This wasn't a thread for people to showcase their architecture, it was a thread to give someone suggestions on how to do things.

Exactly. I asked what I thought was a perfectly valid question: Why are you hard-coding several functions to perform database queries when you could achieve the same thing with a single generic function?

We were pointing out drawbacks to your architecture based on that very point.

Considering that my architecture has been working for several years these "drawbacks" have not been any genuine hard faults, but about hypothetical situations or different interpretations as to how various "rules" should or should not be implemented. I have built working code according to *my* interpretation of the rules, and I see no value in amending it to fit in with *your* interpretation of the rules as I judge *your* interpretation to be going far beyond what is reasonable.

Just because you never think you will use anything other than SQL doesn't mean no one will ever use (anything other than) SQL.

SQL databases dominate the market TODAY, and will do so for the forseeable future. I see no point in creating code to deal with non-SQL databases until their usage becomes significant. Is this an unreasonable view to take? How many other infrastructures have allowed for this unlikely event?

You basically started the entire argument by pointing out a drawback in someone else's architecture that was using a data mapper which an extremely valid, highly used, highly flexible, and highly successful method.

It may be a widely used method, but I was simply pointing out that it required multiple hard-coded methods in multiple classes where I have achieved the same result with a single generic method in a single class. Others then responded by saying "your opinion is irrelevant because your whole architecture SUCKS".

Then you proceeded to act absolutely shocked and mortified when someone pointed out a drawback in your architecture .....

I repeat, I do not see that not providing the ability to switch an existing application from an SQL database to a non-SQL data source is a "drawback" which is worthy of serious consideration.

Q1: What percentage of today's web applications use a non-SQL data source?

Q2: What percentage of today's web applications are likely to be ported from an SQL database to a non-SQL data source?

Until this type of switch becomes an actual requirement in the *real* world I will continue to regard it as unreal, hypothetical, academic and unimportant. Therefore it's omission from my infrastructure would not seem to be that much of a *drawback* after all.

[Tony Marston]

I cannot point to any chapter and say "this says that what I am doing is valid", just as you cannot point to any chapter and say "this proves that what you are doing is invalid".

I wouldn't make such a claim. I don't own those books and I am not positing a methodology. I just thought it might be an easy way for you to establish a more credible argument.

If were make a claim and others disagreed I might look to such authoritative sources and quote them (with annotation and interpretation as I deemed appropriate) in support of my position.

The problem lies in the fact that the only documents any of us can quote contain the original statement from which we made totally different assumptions or interpretations. Neither of us can prove that our assumption is the only valid assumption as there are no other quotable sources.

Q1: If a statement is open to interpretation does it identify a fault in that statement, or does it mean that any interpretaion is valid?

Q2: Does it mean that different interpretations may be valid depending on individual circumstances or context?

Q3: If neither interpretation can be said to be invalid, then why can't we each be left alone to go our own way without being told "your interpretation SUCKS, therefore everything you do based on that interpretation also SUCKS"?

[Helge]

Closed.