Guidelines for Using Linq Objects / Data
I am a new asp.net programmer and I just asked this question which left me more general.
What are the current best practices for Linq objects and data? In particular, when; dim, new and dispose of.
Also with regard to objects that are used in many different areas on the same page, for example. custom data object. Should they be a module or created in each area?
If anyone can give me cliff notes according to best practices, or even a link to an article that describes them, I'd really appreciate it.
source to share
Quick thoughts (I'm sitting in a meeting, so bad me)
For ASP.NET, the maximum lifetime of a data context is one post or postback. You can create more than that, but they will all die when the page is unloaded. Yes, you must dispose of them explicitly; the using statement is the best way to handle this because it will automatically call dispose when the block ends:
using (NorthwindModel nw = new NorthwindModel())
{
do stuff
}
The data returned from a LINQ query does not disappear with the data context, but at this point it is no longer associated with the context and changes can no longer be used to update the database. (You can always create a new context, then attach it as a new entity, or re-request and merge the changes, or whatever suits your needs.)
Be aware that a LINQ query is not executed until you need to evaluate the data. It is a very simple mistake to store a query when the data context is deleted and then when the query needs to be run, it cannot because it was created using a data context that no longer exists. There are two general ways to handle this.
- Process the query results inside a use block for the data context.
-
Force the request to be executed, usually with .ToList () or some other method that will generate the dataset:
MyCustomers list = (from c to nw.Customers select c) .ToList ();
Executes the request, copies the data into an enumerated collection, and provides a collection that can be returned to the calling method. However, these objects are now separate from the context, so they cannot be used for updates.
If you are doing CRUD with LINQ, it is a good idea to use the same data context for all updates, deletes and inserts, and then call SubmitChanges () once for all changes. This ensures that they run as a single transaction. (The data context will generate a transaction for each call to SubmitChanges if no transaction is already in progress.)
If you want to select one item in a query, use FirstOrDefault (), not First (). First () will throw and exclude if nothing matches the selection criteria, and FirstOrDefault () returns null. Very good to know.
Other than that, have fun and try a lot of things. LINQ will change the way you think about data.
source to share
Typically, you want to pass data as parameters to functions and type dependencies as arguments to a constructor. So, for example, a linq data context is likely to be something that your type depends on working and therefore needs to be injected into the constructor. The values used to find data in your context will change quickly and be reused for the same context and therefore will be functional parameters of your type.
If, however, your type is built to perform operations on multiple contexts during its life cycle, you might consider passing the context as parameters to a function, but this is likely to indicate a design problem more than anything.
As far as instantiating data contexts within the scope of a type, there really is no reason to have this overhead in your functions unless the lifetime of your type is guaranteed only for the lifetime of the function call itself. Even if this is the case now, it may not be at some point in the future, and therefore it is best to design your types with this case in mind.
source to share