Questions For Entity Framework Gurus
-
I'm going through a decent EF 4.0 book, and a couple of things came to mind. I'm used to using LINQ To SQL, in my DAL I have standard CRUD methods, such as:
public void UpdateCompany(CompanyEntity Company)
{
using (var dc = getDataContext())
{
var company = (from c in dc.Companies
where c.CompanyId == Company.Id
select c).First();
if (company != null)
{
company.CompanyName = Company.CompanyName;
company.IsActive = Company.IsActive;
try
{
dc.SubmitChanges();
}
catch (Exception e)
{
throw e;
}
}
}
}- If I understand what I'm reading correctly, you wouldn't really do this, as creating a new instance of the data context in each method won't work because of the change tracking in EF. It seems like you would use a single instance of the dataj context. I could use an example of a DAL that works with EF, if anyone has one. 2) Also, in my example I'm using my own entities, which are simple POCO's. Using EF I would use the entities that were generated. But they seem rather heavy compared to POCO's. In a situation where the DAL was accessed via a WCF app, would you use these entities? Thanks
If it's not broken, fix it until it is
-
I'm going through a decent EF 4.0 book, and a couple of things came to mind. I'm used to using LINQ To SQL, in my DAL I have standard CRUD methods, such as:
public void UpdateCompany(CompanyEntity Company)
{
using (var dc = getDataContext())
{
var company = (from c in dc.Companies
where c.CompanyId == Company.Id
select c).First();
if (company != null)
{
company.CompanyName = Company.CompanyName;
company.IsActive = Company.IsActive;
try
{
dc.SubmitChanges();
}
catch (Exception e)
{
throw e;
}
}
}
}- If I understand what I'm reading correctly, you wouldn't really do this, as creating a new instance of the data context in each method won't work because of the change tracking in EF. It seems like you would use a single instance of the dataj context. I could use an example of a DAL that works with EF, if anyone has one. 2) Also, in my example I'm using my own entities, which are simple POCO's. Using EF I would use the entities that were generated. But they seem rather heavy compared to POCO's. In a situation where the DAL was accessed via a WCF app, would you use these entities? Thanks
If it's not broken, fix it until it is
Am no expert here but my general approach is that you create a context in a using block per action you need to perform. For example Adding an Order item to a database create a single context, add the order and order items using that context then commit the changes. This means that if you action has one part that fails then none of it will get committed, and reduces the overhead of creating the context to one per action the user takes not creating one per item that needs adding to the database. I have also use EF in a service and it performs well enough for my needs, if it speeds up your development and performs well enough then why not use it.
-
I'm going through a decent EF 4.0 book, and a couple of things came to mind. I'm used to using LINQ To SQL, in my DAL I have standard CRUD methods, such as:
public void UpdateCompany(CompanyEntity Company)
{
using (var dc = getDataContext())
{
var company = (from c in dc.Companies
where c.CompanyId == Company.Id
select c).First();
if (company != null)
{
company.CompanyName = Company.CompanyName;
company.IsActive = Company.IsActive;
try
{
dc.SubmitChanges();
}
catch (Exception e)
{
throw e;
}
}
}
}- If I understand what I'm reading correctly, you wouldn't really do this, as creating a new instance of the data context in each method won't work because of the change tracking in EF. It seems like you would use a single instance of the dataj context. I could use an example of a DAL that works with EF, if anyone has one. 2) Also, in my example I'm using my own entities, which are simple POCO's. Using EF I would use the entities that were generated. But they seem rather heavy compared to POCO's. In a situation where the DAL was accessed via a WCF app, would you use these entities? Thanks
If it's not broken, fix it until it is
With EF 4, you can work with straight POCO's. Here's a sample of a simple POCO.
public class Customer
{
public int CustomerID { get; set; }
public string FullName { get; set; }
public DateTime DateOfBirth { get; set; }
}Now, to expose it for others to use
public class MyContext : ObjectContext
{
public MyContext() : base("name="Myentities", "Myentities")
{
Customers = CreateObjectSet<Customer>();
}
public ObjectSet<Customer> Customers { get; private set; }
}And that's it - a basic simple POCO with context and very, very lightweight. If you want to use the POCO over WCF, just change it so that it looks like this:
[DataContract]
public class Customer
{
[Key]
[DataMember]
public int CustomerID { get; set; }
[DataMember]
public string FullName { get; set; }
[DataMember]
public DateTime DateOfBirth { get; set; }
}*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier