SitePoint Sponsor |
|
User Tag List
Results 101 to 110 of 110
-
Jan 26, 2005, 19:54 #101
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by kuato
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, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Jan 27, 2005, 03:13 #102
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by mjlivelyjr
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.
Originally Posted by mjlivelyjr
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.
Originally Posted by mjlivelyjr
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.
-
Jan 27, 2005, 03:49 #103
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Brenden Vickery
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.
-
Jan 27, 2005, 04:21 #104
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Super Phil
- 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 ......
Originally Posted by Super Phil
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".
-
Jan 27, 2005, 10:58 #105
- Join Date
- Dec 2003
- Location
- Post Falls, ID, US
- Posts
- 92
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
Originally Posted by Tony Marston
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).
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.
Originally Posted by Tony Marston
Originally Posted by Tony Marston
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....".
Originally Posted by Tony Marston
Mike Lively
Digital Sandwich - MMM MMM Good
-
Jan 27, 2005, 13:29 #106
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
and others too, when I get the time to write the DAOsDoubtful 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.
-
Jan 27, 2005, 15:59 #107
- Join Date
- Jun 2003
- Location
- Melbourne, Australia
- Posts
- 440
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
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.)Zealotry is contingent upon 100 posts and addiction 200?
-
Jan 28, 2005, 04:41 #108
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by mjlivelyjr
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.
Originally Posted by mjlivelyjr
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?
Originally Posted by mjlivelyjr
it should be possible to replace Oracle with an alternative database without any impact on the data access tier (or any tiers above it)
Originally Posted by mjlivelyjr
Originally Posted by mjlivelyjr
Originally Posted by mjlivelyjr
Originally Posted by mjlivelyjr
Originally Posted by mjlivelyjr
Originally Posted by mjlivelyjr
Originally Posted by mjlivelyjr
Originally Posted by mjlivelyjr
Originally Posted by mjlivelyjr
Originally Posted by Tony Marston
-
Jan 28, 2005, 05:02 #109
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by auricle
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"?
-
Jan 28, 2005, 05:52 #110
- Join Date
- Oct 2001
- Posts
- 2,686
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Closed.
Bookmarks