SQL dependencies

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

For more complex queries (which you seem to be avoiding for now), this could be several lines of query code to get to the stuff you want
Yes and no...I'm a real stickler for organization and so it's only natural I follow a divide and conquer approach with software development. If I found something was requiring tons of direct calls - it's highly likley I could refactor and abstract that code into it's own higher level class.
Sooner or later you'll spend more energy organizing these direct database calls than if you reorganized into wrappers.
How so? Unless...I'm guessing we not on the same level here as I just said they will likley be wrapped when complexity sneaks in...just not as a Data Wrapper or ORM in the strictest sense.
Okay, here's the thing: sometimes there are required dependencies. It makes no sense for a clock widget not to have a dependency on some time mechanism. It makes no sense for a FruitMapper not to have a dependency on the Fruit object, which it creates. You can't "remove" the dependencies, but you can make them easier to move around by using a separated interface
Thats obvious. But you need to understand your requirements (ie: target audience & feature requests, etc) to understand when abstraction is needed and/or dependency management becomes an issue. I am confident, at this level, the technique I am using is the best approach considering all factors.

I wanted to start a disscussion on using this approach not an argument on what someone thinks is a better approach. I've been in the game long enough I think I'm capable of making an executive decision like this... :lol:

Oiee...sorry man...long day and I'm frustrated...perhaps I have already exhausted all pros and cons of this approach...and thus left no one with anything left to say, other than to turn this topic into a disscussion of ORM and/or Data Mappers. 8)

I'm interested in hearing comments like:

"Sooner or later you spend more time managing direct SQL calls then you would dealing with an Data Mapper"

That was good, made me think twice...although I seen that coming...it never hurts to hear the truth more than once. ;)

Anything else?

Cheers :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Hockey wrote:Like I said....different levels of abstraction...you appear to be one level up...I'm thinking DAL and you guys are thinking Model...
But Domain Model classes and Data Mappers are probably the key examples of DALs. They abstract the underlying data into a usable form. Model classes provide the easiest and most flexible way to abstract whats underneath. And O/RM is really the automated pinnacle of DALs.
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

In my experience DAL and Model are different things.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Hockey wrote:In my experience DAL and Model are different things.
I am not sure that DAL is an actual software term ... it is really a Microsoft moniker for a click-a-bunch-of-buttons query and button builder. In "my experience" it comes from Access and is a way for non-programmers to build such things. So I am really not clear on what it is you are looking for, but DAL obviously has some specific meaning to you. If you can specifically describe that .......
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

I assure you that DAL (Data Access Layer) is a much a software term as "Model" in MVC or Data Mapper, etc.

Whether you insist on calling them the same thing or seperating them to describe different entities in a software system is a matter of experience, preferance and system architecture and understanding software requirements.

In my situation, they are different... :)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Yah, Data Access Layer is a term, but it's not a very specific term. You could be using Data Mappers, you could be Row Data Gateways or Table Data Gateways, you could be using an ad hoc collection of mysql_query()s, etc.

Model, perhaps more accurately said as Domain Model, on the other hand, describes a very specific approach to organizing business logic, i.e., by modeling it after the objects it represents, and usually comes along with Data Mappers.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Hockey wrote:I assure you that DAL (Data Access Layer) is a much a software term as "Model" in MVC or Data Mapper, etc.

Whether you insist on calling them the same thing or seperating them to describe different entities in a software system is a matter of experience, preferance and system architecture and understanding software requirements.
I Googled "Data Access Layer" and almost every result was about .NET. There was a Wikipedia entry that makes it sound a lot like a Data Mapper. Hence my confusion.
Hockey wrote:In my situation, they are different... :)
That's why I asked for some more specifics on what you want to do. I'd love to help! :)
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

arborint wrote:
Hockey wrote:I assure you that DAL (Data Access Layer) is a much a software term as "Model" in MVC or Data Mapper, etc.

Whether you insist on calling them the same thing or seperating them to describe different entities in a software system is a matter of experience, preferance and system architecture and understanding software requirements.
I Googled "Data Access Layer" and almost every result was about .NET. There was a Wikipedia entry that makes it sound a lot like a Data Mapper. Hence my confusion.
Hockey wrote:In my situation, they are different... :)
That's why I asked for some more specifics on what you want to do. I'd love to help! :)
Cool. :)

The DAL in my case is a low level API providing access to a data medium (XML, DB, etc). It provides a fast, efficient flex point something like AdoDB but medium agnostic (XML, MySQL, MSSQL, CSV, etc) - I dislike DB abstraction layers, personal preference. :P

The problem I believe is dealing with SQL dependancies...but after some more thought last night in regards to AC suggesting dependency removal was wishful thinking....it got me think thinking...

I think I should start another topic though. :P
Post Reply