Linq

[Guest]

Hi All,
I want to start some kind of debate or poll on Linq, the question is:

Do you think is a good idea to work with Linq in the future?
Most of the articles out there are not very impartial, and are embracing
Linq as an evolution, while MVPs or wannabes are making tutorials as they go,
without questioning themselves (at least not publically): Is the best way to
go?

As the intro in the article:
http://msdn2.microsoft.com/library/bb308959.aspx, "After two decades, the
industry has reached a stable point in the evolution of object-oriented (OO)
programming technologies", instead of recollecting the benefits at this point
of OO and n-tier architectures, there is an growing interest of taking an
step back.

What is the reason to query on objects, for example, the query should be
done at a lower layer, right?

This is an open debate, but keep it clean!

Regards to all and happy programming

 

[Miha Markic]

Definitely, LINQ is the future here.
However, I think you are messing apples and computers here.
I assume you are speaking about LINQ to SQL (ORM product with LINQ).
Correct?

 

[Frans Bouma [C# MVP]]

Hi All,
I want to start some kind of debate or poll on Linq, the question is:

Do you think is a good idea to work with Linq in the future?

Linq is just a part of the puzzle. Create, Update and Delete actions
on databases aren't covered by Linq. ALso, Linq on objects etc. is a
nice addition.

Most of the articles out there are not very impartial, and are
embracing Linq as an evolution, while MVPs or wannabes are making
tutorials as they go, without questioning themselves (at least not
publically): Is the best way to go?

It's a way to work with data. Personally I'm not impressed by the
syntaxis, simply because it's overly complicated at times (left/right
joins are a pain to specify, IN queries aren't obvious, you can't
specify in the syntaxis if you want to use joins or subqueries for
predicates, in-select list scalar queries or derived tables etc. that's
all up to the Linq provider implementator, so one big problem will
arise: the developer using Linq to target a DB has no way to TUNE the
query from C# or VB.NET. This can be a huge disadvantage. Often an O/R
mapper offers these tuning aspects in their query api, precisely
because the developers of these or mappers know that tuning a query is
key for acceptance of an o/r mapper in a bigger organization.

My biggest gripe with linq other than the syntax (which is sometimes
silly) is the deferred execution. That alone will bring a lot of
problems and IMHO way more problems than it solves.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Miha Markic]

My biggest gripe with linq other than the syntax (which is sometimes
silly) is the deferred execution. That alone will bring a lot of
problems and IMHO way more problems than it solves.

True, it might and probably it will. However, I fail to see a better
alternative. A developer has to distinguish between an expression tree and a
query. If he/she doesn't then no tool can help.
If somebody wants to be on the safe side then ToList() has to be called
after query is built.

Anyway, perhaps MS could add a dialog box that pops up when you start
typeing a query:
"Please, click OK if you understand what deffered execution is. Otherwise VS
will erase your LINQ code."

[OK] [Cancel]

 

[Frans Bouma [C# MVP]]

True, it might and probably it will. However, I fail to see a better
alternative. A developer has to distinguish between an expression
tree and a query. If he/she doesn't then no tool can help. If
somebody wants to be on the safe side then ToList() has to be called
after query is built.

I think it could be solved as every other o/r mapper solves it: by
seeing the query definition as a definition, not as a resultset. It's a
combination of concerns now and that's a code smell.

So if you could do:

var q = from c in nw.Customers select c;

and later on you only could do:

List<Customer> customers = q.Execute();

you would have a better system. Not only is it CLEAR what happens, but
it also separates resultset from query specification.

The above example isn't even great though. For example if you're
reading and updating entities in a loop, you have to have the context
in the loop you're reading and updating the entities in as well.
otherwise you can't read in the same transaction as the updates.

Anyway, perhaps MS could add a dialog box that pops up when you start
typeing a query: "Please, click OK if you understand what deffered
execution is. Otherwise VS will erase your LINQ code."

[OK] [Cancel]

hehehe

FB



--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Guest]

In my opinion i think that linq its not the best option, lets imagine that we
want to make moderate changes in the structure of a database, and we have for
other hand, serveral applications that uses linq to this database. Of course,
if we used stored procedures, we have to modify probably all of these, but if
we uses linq, first of all we have to make a lot of changes in code. Not only
in linq sentences, but in some logic objects. After that we have to
recompile, this makes less flexible the environment, and prone to errors.
Another aspect its that, the use of linq breaks the OOP rules.

I think its not good to remove the Data Layer, and insert linq into
bussiness layer.

What do you think?
Regards.
Josema.

 

[Guest]

hello,

I ma actually build ing for instance a big aplication which is based on an
SOA architecture using WCF. All my different layer are clearly defined and my
WCF service run on top of my datalayer which is essentially based on strore
procedure call...
I see the use of Linq for use in buisness logic code for instance an
manipulating XMl document or local object in order to querry data in a
similar way as an SQL statement. But in enterprise solution I definirtly not
myself at least using link for that.

As a personnal experience, as a new thing is comming out, a lot of noise
around this new stuff and everyone say Wowww.. this is mainly happen when you
get a simple demo to show you how it can be usse. but afterwards when you
strat to digg deeper and try to figure out if you could impleemnt it in your
project a lot of question comes like :

What do I have more by using it ?
Do I reaaly need it ?
I know that it exist but any added value in my scenario ?

I have seen similar question when selecting a language like :
Do I have to use PHP or ASP.net or Java or...

there is so many language on the field, simply select the one that you are
use to and that you are sure it will satisfy your requirement or no
limitation will occurs.
Poeple who play with PHP will tell you that its the best, but it is not the
one to chose for enterprise solution or e.commerce for sure.

So link or not link, its a more a nartural choice based your own logic and
not becasue it exist I have to use it.

That my opinion

regards
serge
MCAD.NET