Page 2 of 2
Posted: Sun Jan 14, 2007 8:21 pm
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...
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.
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

Posted: Mon Jan 15, 2007 1:06 am
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.
Posted: Mon Jan 15, 2007 10:39 am
by alex.barylski
In my experience DAL and Model are different things.
Posted: Mon Jan 15, 2007 2:04 pm
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 .......
Posted: Mon Jan 15, 2007 4:20 pm
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...

Posted: Mon Jan 15, 2007 4:32 pm
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.
Posted: Mon Jan 15, 2007 4:38 pm
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!

Posted: Mon Jan 15, 2007 5:04 pm
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.
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.
