A small question. I am using LinqToSql in an n-tier application. I have a datacontext, and I wish to manipulate CRUD operations. I'd rather my datacontext not have object tracking for reasons of scalability. But then, when I have object tracking set to fault I cannot use the built in CRUD operations the datacontext has to offer. So... how do I work around this?
Thank you very much in advance.
You can use Stored Procedures, but with object tracking off, you will not be able to use the "SubmitChanges" method to persist new objects/changes to the database. (also, just fyi, be sure to look into ADO.NET Entity Framework before committing to LINQ to SQL)
Scott Gu - LINQ to SQL Stored Procs
http://weblogs.asp.net/scottgu/archive/2007/08/16/linq-to-sql-part-6-retrieving-data-using-stored-procedures.aspx
-
LINQ to SQL overview
http://msdn.microsoft.com/en-us/library/bb425822.aspx
-
ADO.NET Entity Framework Overview
http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx
Related
I'm trying to design application that will have UI with database in the backend.
I will be using Linq-to-SQL as the database layer to update and insert.
Now I'm trying to find out the best practice to use in designing the project, suppose I have 2 tables in the DB (Customers, Orders)
Shall I depend on the generated Linq-to-SQL classes, or shall I still create classes for Customers, Orders?
Shall I wrap the generated Linq-to-SQL inside another class to add validations?
I hope my questions are clear.
L2S is in my opinion an excellent light-weight data access method. If you have control over the database and have limited application data processing logic it is often a good choice.
If you have a two-tier app with a UI communicating directly with the DB then you can depend on the L2S generated classes. If you have a multi tier app with a client communicating with e.g. a WCF service you probably need Data Transfer Objects.
Use the partial methods on the L2S classes for validation.
I think you should use other ORMs for better implementation DAL for example Entity Framework or Nhibernate this ORMs allow you Model First approach without attributes
and the validation logic you should separate in other classes for exmaple MyEntityValidator
And also good approach to use the Repository pattern this pattern allow doesn't depend on Data access EF or Nhibernate
and look at this Entity Framework and Repository
What are the pro's and con's of using "Linq to SQL" and core ADO.NET technology for access databases?
Advantage
No need to create business objects dbml files will do for you
No need to worry about writing queries because linq2sql convert your statment in efficient queries
Important is Lazy Loading of related objects
Disadvantage
Disconnect linq is not supported i.e you cannot deatch you objects form DataContext object. for more detail : Most efficient way to update with LINQ to SQL
I have the same view point as this post, I've yet to find any major disadvantages of Linq.
I have built a number or application and websites using Linq and found it to be extremlly simple to use
http://forums.asp.net/t/1520157.aspx
comment by BoogleC
Regards
Sp
Id also be carefull about how you write you LINQ statement. Sometimes its better to compile your Linq rather than not as every single run of the Linq query is fully parsed every time it happens. See below linq
http://www.codinghorror.com/blog/2010/03/compiled-or-bust.html
I wouldn't recommend LINQ to SQL at all as it is effectively dead (you don't want to be writing legacy code, right?). Microsoft is no longer developing it and they recommend using the Entity Framework instead (see here), however, if you are interested in using an ORM, I would strongly recommend looking at NHibernate.
I'm working on a project where most of the times I'm going to call database with a stored procedure and I'm a little bit confused what should I do. Options are not just restricted to Sql to Linq and EF. If there are any better options please suggest them too.
UPDATE - Reason for using SPs
I've to apply logic in many of the stored procedure. Apart from this, my intention to use SPs for CRUD operation is to improve performance.
Thanks in advance.
ORM tools wasn't designed to be used only with stored procedures (but they could), it will be very difficult to map data on eneities and perform all operations using EF. You can relay on this guide, but I need some details to suggest something more meaningfull.
Using LINQ to SQL make application development faster but dissolves the logical layers in the application. The data access layer and the business objects layers almost have no identity, they sit in the same dll. Does any one has an idea on how to develop an enterprise level application using LINQ to SQL. How do we cleanly separate the business object and the LINQ generated entities ? How would they communicate, how would data be transferred between our business objects and LINQ entities. Any article or any suggestions towards this would be greatly appreciate. Thanks.
We're using L2S for our next generation of software that manages our plant operations and related applications. This is for a $2.5B thin film solar company. We have built a clearly defined L2S based n-tier application framework.
We also created our own code generator to generate an application set of entities, a L2S set of entities, a business logic layer and data access layer. The L2S set of entities is for back-end use only. The application entities (which have no L2S plumbing built in) is for transferring data back and forth from application to server. We use WCF for application tier to server tier communication.
Our applications use WCF to call to the back-end businss logic layer for data processing. The business logic layer calls to our data access layer for low level Linq based data access. Our application entities get passed to and from our back-end. In the back-end, we have very efficient mapping that maps an application entity to each L2S entity.
Works very well for us.
Randy
You can get very far with L2S (as StackOverflow has proven), but IMHO Linq2SQL is not well suited (nor intended, I think) for "enterprise level applications".
Now that Entity Framework 4.0 has been released, you may want to consider going with EF instead. It supports POCO and will allow you do have a much nicer layered architecture.
Check out:
The ADO.NET Entity Framework
ADO.NET C# POCO Entity Generator
I recently ported a substantial code base from L2S to EF 4.0. Since EF now supports lazy-loading, you can have a very smooth transition from L2S to EF, leveraging the advanced features of EF only when you need them.
I use L2S at my module. The problem occurs while I'm using the default DNN entities at the same TransactionScope with my L2S data access, then I get a DTC request which I want to avoid.
How can I share the connection/transaction for both DNN entities and my L2S data access?
Sadly, as stated here - transactions are currently not the strong part of DNN (5.1.X), thus L2S operations should not be entangled with DNN core operations to prevent transactions escalation.
I don't know about DNN, but the L2S datacontext has a constructor that takes a SqlConnection (well, a IDbConnection of a SqlConnection) as a parameter. So if you have a connection already established, just pass it in to the L2S datacontext when you create a new instance.