dashCommerce

I have changed a few things to LINQ for SQL and it seems a lot more elegant and performant than Subsonic has this been considered / will it be in v 3.0 ?

Regards,

Ben

The 3.0 Release will be based on .NET 2.0, but we will probably jump to 3.5 with the 3.1+ release. I'd like to hear more about your experiences with Linq, specifically vs. SubSonic. Do you have any measurement to back up the speed / performance claim?

I'd like to ask: where and how linq is faster than Subsonic?

My opinion is that Subsonic is an excellent architectural choice for many reasons that extend beyond how fast the code executes.

I recently needed some simple data from an existing table in a foreign database.  While we use Subsonic, and this table happened to be a subsonic cms table, I didn't want to gen the whole DAL just for one table.  Using LINQ for sql (for the first time, mind you), I was able to quickly map my tables to a class and get the data I needed.  However, when I have a database with many, many tables and I want full, programatic, object based crud capability on everything, nothing is faster than my Visual Studio "Subsonic" command.  I can add an entire database to my project and with nothing more than two lines in config, have a DAL for that in seconds.  Then, I can work to extend those objects in any way I see fit and use them in my app.  There are more things to consider than just "how fast a query runs".  If you are using good design patterns, caching should be simple and transparent.   I can attest that Subsonic is very fast and pretty much stays out of the way.  I've also used nHibernate extensively and will report that nHibernate provided much more capability but caused alot more problems that required coding solutions.  Additional code is bad, I have a young boy growing up too fast to waste time writing data access code.

The father of Subsonic is now a Microsoft employee as a result of his excellent work on Subsonic.  That says quite a bit.  Microsoft recognized the value of his work, and how it compliments the tools and languages we use, so much they hired hizzazz.

What exactly would be a good catalyst for a switch from Subsonic to Linq?

 Thanks for hearing my opinion...

:)

Maybe LinqToSubSonic will come out some day.

About SubSonic being slower then LinqToSql do you have anything to back that up?

http://blog.wekeroad.com/2007/12/14/aspnet-mvc-choosing-your-data-access-method/

 That's a definite possibility.  There's a link2nHibernate so its certainly feasable.  

All of these are layers on top of existing technologies, so I'd like to look at this objectively. If there is an advantage to moving to Linq then I'm fine doing it, but a couple of things:

1.) There should be some ROI because making the switch will take some time and effort.

2.) I'd like to get the ROI substantiated - meaning if there is a perf improvement, then let's get it tested and documented.

From a newb point of view, I don't think it much matters - they'll roll with whatever technology is there.

I've become increasingly unhappy with SubSonic, so, while I don't think it is a bad product, I am open to looking at alternatives.

I think nothing beats writing your own data and business layer which I try to do most of the time but recently i've been playing with LinqtoSql for a project of mine and i'm loving it.

It might not be as good as subsonic but because it's intergrated nicely in visual studio i'm already familier with the Linq syntax, which I found easier to pick up than Subsonic. I think Linq will be easier to pick up by newbies because there is going to be a lot of documentation and guides on it. Since it's backed by Microsoft it's probably a safe bet not that i'm saying Subsonic won't be around, it's just a lot easier convincing your boss to should use Linq rather than an 3rd party open source ORM.

Then again dashCommerce is open source..

Naz - your experience with LinqToSql is in line with some others that I have spoken with. Down the road, I'd like dashCommerce to become more scalable - and designed to scale out. While this is not a limitation of SubSonic, the collection heavy nature is, so my feeling right now is that SubSonic will go away at some point as we turn to making things scale out.

Personally, I'd like to see 3.1 focus on getting the "scale out" architecture in place, so I think we will be able to pick and choose where we start moving away from Subsonic. Some folks have mentioned this in the forums, and I agree.

Also, as a cool note - I came up with a model for an Order Pipeline (someone in the forums had mentioned wanting to see a pipeline model), but I'm not really sure how far to take it. Does anyone here have experience with this? Any opinions?

-- EDIT --

It's not so much an Order Pipeline as it is a Price Pipeline - allowing you to adjust the price by running it through a series of Pricing Strategies. It uses a Chain of Responsibility pattern.

I used LinqToSql for a project and was not at all happy with it once you move the Query out of the page itself.
The Linq Syntax is great (and this will hopefully come to SubSonic in the version after 2.1)

When working with LinqToSql you start getting all kind of problems when working with a multi-tiered application (when passing objects thru layers) for example you have to know if the Entity is already Attached or do you have to Add it (this works fine most of the time if the Query's is on the aspx page itself) and also saving to the DB saves the whole Context to the DB.

And SubSonic added a new Query Engine that is very easy to learn/use and is very powerfull You can query only the columns you want add Joinsand more

LinqToSql only supports SQLServer (while with SubSonic I don't think it is so hard to move dC to use other DB's)

I would really like to see some tests where LinqToSql is faster then SubSonic.

SubSonic is OpenSource:)

(There are workarounds for some of the problems of LinqToSql but then you have to add another layer into the mix. Rick Strahl has some nice blog posts and helpers)