Entity Framework and LINQ

Hey,

I was wanting to get peoples impressions of the Entity Framework and LINQ.

I like the idea of having the mapping of classes to the relational databe handled but as I understand it for this to work we have to use LINQ.

My manager isnt keen on having query code in the business end as he is adament that this should be handled by Stored Procs by the DBA's. His argument is that they are better placed to build tuned queries in SQL Management Studio.

Any peopples thoughton the above is appreciated.

Hey,
If you're using an ORM like NHibernate, you don't need to use LINQ.

So I could have a stored proc i.e.

select a.x, b.x from
a innerjoin
b on a.y = b.y

and two classes classa and classb, using nHibernate I could map a.x to class a and b.x to class b.

If I had these classes bound to a datagrid and updated a row, presumably I would have to write a stored proc to handle any column, something LINQ would automatically handle?

Is the use of SPs only available with Hibernate or in the MS Entity Framework. What are peopples general opinions on LINQ over SPs

Sorry I missed the stored procedure part. As far as what I have seen with NHibernate and other ORM models, stored procedures are irrelevant, simply because the the ORM doesn't care what the underlying data storage model is. An ORM lets you switch between databases.

There are different schools of thought as to where the business logic should reside. I have always been in favor of keeping it close to data aka "database stored procs". There are other schools of thought and if you're building a product it would be good if you weren't going to tie yourself down to a single database.

In that case you would be better off using LINQ.

As far as performance goes, I fear your manager is not completely wrong. Stored procedures can be extremely efficient in doing certain things, where an ORM might take time.

With faster and faster computers and good network connectivity, this too might be a thing of the past.

I hear with SQL Server 2005, the performance gap between stored procedures and direct queries has shrunk.

FishGuy, it really depends on how you want to design the application. If it's a closed environment where the only way users can enter data is through the app front end, it really doesn't matter (from an architecture perspective) if you use stored procs inside the database or build a business layer with LINQ to handle things. However if you want to expose your application functionality through APIs, you may want to look at LINQ more closely. Another important point is building all the business logic in the application layer will allow you to deploy parts of the application on separate application servers, while leaving the database server the same. Kind of a distributed architecture. This works well for applications which need to scale up. If you are heavily into stored procs, scaling up at the database level could be a big challenge.

.

Thanks, for your replies.

I will have to experiement as with a mock project and see how it could work for me. Im interested in different design patterns but totally at a loss as to what technology I should be using for what i.e. WCF, WPF, MVC, Entity Framework, Binding to Datasets, Object Collections.

I know there is no easy answer and it probably depends on each situation and it's merits but I was just interested in what others thought in the community.

Each pattern addresses a specific design issue. So they aren't really alternatives per se. For e.g. you cannot decide between WPF and WCF, as one deals with presentation/client side rendering, while the other deals with communication between different components of your application. You could have a combination of two, i.e. you could have a WCF framework for communication, but build each service/class component using Entity Framework.

.