C# – Implement Business Logic on Entity Framework

LINQ to SQL only supports 1 to 1 mapping of database tables, views, sprocs and functions available in Microsoft SQL Server. It's a great API to use for quick data access construction to relatively well designed SQL Server databases. LINQ2SQL was first released with C# 3.0 and .Net Framework 3.5.

LINQ to Entities (ADO.Net Entity Framework) is an ORM (Object Relational Mapper) API which allows for a broad definition of object domain models and their relationships to many different ADO.Net data providers. As such, you can mix and match a number of different database vendors, application servers or protocols to design an aggregated mash-up of objects which are constructed from a variety of tables, sources, services, etc. ADO.Net Framework was released with the .Net Framework 3.5 SP1.

This is a good introductory article on MSDN: Introducing LINQ to Relational Data

Typically, the "best practice" approach would be something like this:

• in your Data layer, you have EF entities that get loaded from and stored back to the database

• in your Business layer, you have your own domain objects (just plain C# classes) that represent the data that your app needs to work on. Those can be more or less identical to a data layer entity, or they can contain several "atomic" entities to make up a business object, or they can be vastly different. To alleviate the need for a lot of left-hand-right-hand-assignment statements (to move property values back and forth between data layer entities and business layer objects), you should check out tools like AutoMapper that make it really easy to set up "mappings" between similar object types and allow you to easily assign those types back and forth

• your UI layer(s) will then visualize and represent Business layer objects to the user for information and/or manipulation

The benefit is that your business layer domain model represents the actual business objects you're working with, and becomes more or less independent of how those are really stored in the data layer. Also, this avoids "glueing" your UI layer to a particular data access technology.

Of course - that's the recommended best practice for an enterprise-scale app, where you might need to swap out the data access layer etc. For a simpler app, you might skip those practices, knowing what you're doing, and that you're "locking" yourself into EF if you use EF entities all the way up through the business layer into the UI. If that's ok with you and your app scenario - there's no particular reason not to do it. EF entities are perfectly valid .NET object classes - they simply derive from a common base class (EntityObject instead of object) and they have a certain amount of "baggage" that comes along. But there's nothing stopping you from using those EF entities all throughout your app.