LINQ terminology

Lazy Loading (or) Deferred Loading
----------------------------------

Refer to : http://dotnetslackers.com/articles/csharp/Load-Lazy-in-LINQ-to-SQL.aspx

Lazy loading indicates the DAL’s ability to load only a portion of the object graph based on some rules. When you add this capability to your DAL, you have implemented the “Lazy Load” pattern (LL).

Lazy loading describes the behavior of an object that doesn’t hold all the data it needs. The object, though, does know how to retrieve missing data on demand. When you load an instance of, say, a Customer entity in a lazy loading model only essential data is loaded—for example, only personal information. Later, when some piece of code needs to go through orders associated with the customer, missing information is located and loaded.


How to disable lazy loading:
----------------------------

NorthwindDataContext ctx = new NorthwindDataContext();
ctx.DeferredLoadingEnabled = false;


Advantage of O/RM (object/relational mapper) tools :
-------------------------

O/RM tools are powerful instruments that save developers a lot of work and are becoming a necessary tool every day. However, you cannot blindly delegate tools the generation of the database code. Make sure you cross-check any T-SQL code and use the SQL profiler extensively during development. If you don’t like the database code being generated, change it. Sometimes you can do better by simply tweaking the O/RM configuration; sometimes you need to manually rewrite the T-SQL code.

Refer to : http://blogs.msdn.com/gblock/archive/2006/10/26/ten-advantages-of-an-orm.aspx


Ten advantages of an ORM (Object Relational Mapper) :
-----------------------------------------------------

1. Facilitates implementing the Domain Model pattern (Thanks Udi). This one reason supercedes all others. In short using this pattern means that you model entities based on real business concepts rather than based on your database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

2. Huge reduction in code. ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

3. Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

4. Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

5. Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a PO and you want to access it's Customer, you can simply access PO.Customer and the ORM will take care of loading the data for you without any effort on your part.

6. Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of POs without any of it's child / related objects, while in other scenarious you can specify to load a PO, with all it's child LineItems, etc.

7. Concurrency support. Support for multiple users updating the same data simultaneously.

8. Cache managment. Entities are cached in memory thereby reducing load on the database.

9. Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

10. Key Management. Identifiers and surrogate keys are automatically propogated and managed.


If your developing short lifespan applications then it really doesn't matter.

If you're developing long standing enterprise level applications there should be a separation of concerns. The business model should not be running CRUD operations. There should also be persistence ignorance which means loose coupling between ui/model and data access. Why? What happens when MS decides to come out with the next grand data access framework in 4-5 years and linq to sql becomes deprecated? You have to rewrite your most of your app just to use the new framework. If you google the underlined phrases you'll find a lot of information on these subjects.