|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
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 -- Jorgebg - MCSD.NET 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? -- Show quoteMiha Markic [MVP C#, INETA Country Leader for Slovenia] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/ "Jorgebg" <Jorg***@discussions.microsoft.com> wrote in message news:052BEC1C-A578-4919-8497-A4AE346445E3@microsoft.com... > 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 > > -- > Jorgebg - MCSD.NET Jorgebg wrote:
> Hi All, Linq is just a part of the puzzle. Create, Update and Delete actions> 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? 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 It's a way to work with data. Personally I'm not impressed by the> 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? 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#) ------------------------------------------------------------------------ > My biggest gripe with linq other than the syntax (which is sometimes True, it might and probably it will. However, I fail to see a better > silly) is the deferred execution. That alone will bring a lot of > problems and IMHO way more problems than it solves. 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] -- Miha Markic [MVP C#, INETA Country Leader for Slovenia] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/ Miha Markic wrote:
> I think it could be solved as every other o/r mapper solves it: by> > 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. 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 hehehe :)> typeing a query: "Please, click OK if you understand what deffered > execution is. Otherwise VS will erase your LINQ code." > > [OK] [Cancel] 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#) ------------------------------------------------------------------------ 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. Show quote "Jorgebg" wrote: > 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 > > -- > Jorgebg - MCSD.NET 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 Show quote "Josema" wrote: > 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. > > > > > > "Jorgebg" wrote: > > > 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 > > > > -- > > Jorgebg - MCSD.NET  |
|||||||||||||||||||||||
Other interesting topics