Coffeehouse Thread

7 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Head First

Back to Forum: Coffeehouse
  • User profile image
    SaraJoRedux

    So, I was origionally going to use stored procedures and active record sets in this project, but the more I read about MVC and LINQ the more I realize iot will make my life SO much easier.

    So I'm going through Scott Gu's tutorial now getting up to speed, I think this time investment will prove worthwhile.

    Has anyone implemented them in a project?

    How does it affect performance? Faster? Slower? Same?

  • User profile image
    jh71283

    quick word about Scotts tutorial: there was a breaking change after that tutorial was written, so instead of .Add(Object) it is now .InsertOnSubmit(Object)

  • User profile image
    SaraJoRedux

    jh71283 said:
    quick word about Scotts tutorial: there was a breaking change after that tutorial was written, so instead of .Add(Object) it is now .InsertOnSubmit(Object)
    Thanks.



    I'm hearing rumors about LINQ not being scalable for larger apps and it cutting down on performance speed.

    Any validity to this?

  • User profile image
    Human​Compiler

    SaraJoRedux said:
    jh71283 said:
    *snip*
    Thanks.



    I'm hearing rumors about LINQ not being scalable for larger apps and it cutting down on performance speed.

    Any validity to this?
    Depends on what you're doing.  Only thing I've seen is doing lots of updates can be slow, but that's because LINQ does pessimistic concurrency.  This is easily avoided by writing your own Add, Edit and Remove stored procedures to use instead.  No performance problems with Selects that I've found yet.  It's quite good at coming up with the most optimized statement possible.

    EDIT: Or is it optimistic concurrency?  I always get those two mixed up.

  • User profile image
    vesuvius

    The principal problem with Linq is that there is no change tracking. It's sweet for small apps, but I would steer well clear of it in larger applications. Sprocs are cumbersome to begin with, but pay you back later. Linq pays you back straight away, but is beyond cumbersome later.

    With Linq it is possible to make something or anything work, but if you want to adhere to patterns and practices, or just simple 'best practices', it is somewhat lacking in maturity. The ADO.NET entity framework is gathering pace, but this is Version 1.0 as far as Visual Studio is concerned and Microsoft will have cut corners. Pragmatism would dictate you wait a while longer.

    You may as well leverage your existing skills, because by the time you've fully learnt this new ADO.NET layer, the project will be in the red!

  • User profile image
    SaraJoRedux

    vesuvius said:

    The principal problem with Linq is that there is no change tracking. It's sweet for small apps, but I would steer well clear of it in larger applications. Sprocs are cumbersome to begin with, but pay you back later. Linq pays you back straight away, but is beyond cumbersome later.

    With Linq it is possible to make something or anything work, but if you want to adhere to patterns and practices, or just simple 'best practices', it is somewhat lacking in maturity. The ADO.NET entity framework is gathering pace, but this is Version 1.0 as far as Visual Studio is concerned and Microsoft will have cut corners. Pragmatism would dictate you wait a while longer.

    You may as well leverage your existing skills, because by the time you've fully learnt this new ADO.NET layer, the project will be in the red!

    Thakns guys, I think I'm going to stick with tradtional stored procs and then go with the MVC.

  • User profile image
    figuerres

    HumanCompiler said:
    SaraJoRedux said:
    *snip*
    Depends on what you're doing.  Only thing I've seen is doing lots of updates can be slow, but that's because LINQ does pessimistic concurrency.  This is easily avoided by writing your own Add, Edit and Remove stored procedures to use instead.  No performance problems with Selects that I've found yet.  It's quite good at coming up with the most optimized statement possible.

    EDIT: Or is it optimistic concurrency?  I always get those two mixed up.
    Also what linq does when you are inserting and updating is it sets up a transaction.

    this is generally a good thing but  it may not know that some tables need to be part of the transaction and others do not.

    but the fact that it will be a trasaction and if it fails it all rollsback is usefull ....

    when I started to use linq I went looking for a .BeginTransaction() and did not find one... then learned it was automatic.

    I have one web service that is using linq to insert orders into a database,  so far all the inserts are for sure less than 1 second.
    how much less I have not yet checked.... but this is a very busy database and has piles of inserts going into it from an older webservice that users sprocs and C# / no linq.

    so far it seems like the two services play well with each other.... both of them hiting the same tables and doing the same job.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.