SUGGESTION: Re-factor Nop.DataAccess.SqlServer to use Entity Framework

Hi Guys,

You doing amazing job, but one thing still painful is doing some modifications in Model e.g. adding new filed to existing table, modification and then implement all this required CRUD manually. When we adding in our projects some new tables  we are using EF for all CRUD, but when we need to do modification in existing model, then we need to use your rules (create SP, add parameters etc) ... and this rules takes pretty much time as well it's boring :) I understand that move to EF is a big and boring job, but this will make nopCommerce absolutely awesome form modification point of view. This will save time to you in future too as i think.
Common guys, all this Stored Procedures is old school, let's move to the modern age of LINQ and EF, today is 2010!

Thanks

Thanks. Go and vote here

as much as i like new things, old school is good school. me like Full handcrafted control. :)

Well, it's all about time. EF and LINQ to EF speed up Model development and maintenance in several times.

sch09 wrote:

Ditto here.

Cool, maybe let's back to classic ASP ? Why use ASP.NET, we don't have so much control as we had in classic ASP lol

Developer have enough control over EF ORM, there is no limitations which could cost so huge performance improvements for development process in case using ORM. And i am not talking about application design now, all model logic should be in one place, not like part of it  in database (SP) and other part in  DataAccess layer code.

Hello guys,

I think a good code generator ( like codesmith or orhers.. ) it's the best choice for creating new Nop modules.
I'm not a great fan of ORM, I like to know what happen behind the scenes. I think SP are still the best choice for multi layers context.

regardless of my previous comment. It is about time to start using EF.

I am not a real fan of the many ORM packages we can find all over the net. If we have to go the ORM route, my suggestion is to stick with what comes with Visual Studio and not depend on other third party tools.

Why code what you can let the framework do for you?
I will say though, I ran into quite a few issues, as far as functionality with foreign keys and such with EF before that in the v4 framework.   I had no choice but to use LINQ to SQL.        EF in the v4 Framework is more mature.   I will slowly be migrating existing projects to it.
LINQ to SQL(extended with partial classes) and DynamicData have been priceless for me in supplimenting open source apps like NOP, Community Server, SiteFinity, etc...

We've already started investigating how we could move nopCommerce to EF 4. It can take some time to take a closer look at the new POCO support in EF 4. I can't tell for sure but maybe we'll do it in the next release.