|
10/14/2008 4:09:00 AM - Mike Y.
|
| |
Not sure I can agree with you here - unless of course you are specifically calling out D-LINQ, in which case it does makes sense to keep it with your DAL.
There are plenty of cases where I would want to (and have) use LINQ's set-based-style operations (Intersect / Union / etc.) against normal collections.
Any thoughts here???
Cheers,
Mike |
| |
|
10/14/2008 7:41:00 AM http://www.lowendal.netq - Patrik Löwendahl
|
| |
Well I sort of agree with your statement about in-memory collections. I would probably put them outside of the DAL put defiantly in some other kind of abstraction.
But yeah the main purpose of this post is LINQ queries that touches database:
"That is, if you query a database the query should be encapsulated in some kind of DAL component"
|
| |
|
10/14/2008 8:22:00 AM - chris
|
| |
| It already is contained in a DAL. The DAL is created for you. Why in the world would you create an encapsulating DAL to encapsulate the DAL created by LINQ? That's idiotic. Are you one of the programmers that has 6 levels of obfuscation built into their "Hello world!" application? |
| |
|
10/14/2008 1:47:00 PM http://www.lowendal.netq - Patrik Löwendahl
|
| |
LINQ is not a DAL. It is a query abstraction. And it's very simple, queries should be in a dal type of component for many reasons but some of the more important are re-use, separation of concerns and maintainability.
Now the object context (data context) might qualify as a dal, but it sure don't comply with query reuse. You want one centralized place where you maintain your query and query structure integrity, you don't want to run around your whole application to find all the places where queries might be. In larger solutions that is a lot of places, using abstractions will help maintainanence.
Or are you one of the developers that put T-SQL everywhere in your application? |
| |
|
10/14/2008 1:55:00 PM http://www.lowendal.netq - Patrik Löwendahl
|
| |
| Let me refrase that, even though LINQ with some kind of context might look like a DAL, the abstraction isn't sufficient to meet the maintainability goals I got. The abstraction is just slightly better then that of the DataAdapter and Typed Dataset. |
| |
|
10/14/2008 3:23:00 PM - chris
|
| |
I'm not sure you are understanding what LINQ actually does. A DAL creates "strongly" typed objects to access and be the intermediary to your data repository for your BLL. This is the same this that LINQ does. Here's an excellent article detailing what I am talking about.
http://www.adamtibi.net/post/2008/08/23/LINQ-to-SQL-The-Data-Access-Layer-DAL-Shrinker.aspx
http://blogs.class-a.nl/blogs/anko/archive/2007/11/01/linq-to-sql-is-the-data-access-layer-dal.aspx
Also, posting fails the first time to your site. I'm told the word is incorrect the first time. I don't change it and click post again and it works. Just FYI. |
| |
|
10/14/2008 4:15:00 PM https://lowendahl.net - Patrik Löwendahl
|
| |
I think there is a confusion here. LINQ doesn't create typed objects, the LINQ to SQL /designer/ or the EDM designer does but LINQ doesn't. LINQ is an addition to VB and C# to add querying capabilities to those languages. It's Microsoft's answer to the Query Object pattern.
But, I don't agree in that LINQ to SQL or Entity Framework generates a Data Access Layer. What it does is generating a strongly typed Domain Model, which has nothing to do with /layer/ of data access. The domain model doesn't even have to know that it's used in data access scenarios. Additionally it creates a strongly typed DataContext (for LTS) or ObjectContext (for EF) derivates.
At best the typed derivates can be called a Data Access Component and don't bring much more to the table then a SqlDataAdapter in terms of abstraction and layering.
The same is true if you create your model yourself and use a NHibernate Session instead of LTS or EF context objects.
A proper DAL, like the repository pattern, encapsulate and abstracts the querying of the store in tidy methods that returns typed objects. Inside those methods you might utilize LINQ as a query language and a typed DataContext. The rest of the application really don't know or care where those objects came from.
With that kind of abstraction you create a neat maintainable model which separates the application from the storage model.
By putting your LINQ queries and data context in a services or UI, that separation never occurs.
Some link love:
Repository pattern: http://www.martinfowler.com/eaaCatalog/repository.html
"Foundations of programming", a neat book explaining these and other OO concepts:
http://codebetter.com/blogs/karlseguin/archive/2008/06/24/foundations-of-programming-ebook.aspx
Domain Model: http://www.martinfowler.com/eaaCatalog/domainModel.html
Thanks for the heads up on the captcha, I'll check that out when I get home. |