.Net Entity Framework

[Pino]

Ok so i'm spending some time with the Entity framework and wondered how you guys structure your projects at the moment it seem I have to generate and instance of the Database entity everytime I wish to do somthing,



ExtLib.DBEntities db = new ExtLib.DedimiEntities();
ExtLib.Products newProduct = new ExtLib.Products();
newProduct.Name = "Test Product";
db.AddToProducts(newProduct);
db.SaveChanges();


Is this the best way to do this? Rather than have "ExtLib.DBEntities db = new ExtLib.DBEntities();" in every function?

[Pino]

After looking around google, seems this is the best way to do it,


public class Data
{
private static MyDBEntities _myDBEntities;
public static MyDBEntities MyDBEntities
{
get
{
if (_myDBEntities == null)
{
_myDBEntities = new MyDBEntities ();
}
return _myDBEntities;
}
set { _myDBEntities = value; }
}
}

[jmcilhinney]

It's not necessarily a great idea to have a single static instance like that. It will end up growing with each data access and keeping data around that you don't need any more. You should actually create a new instance for each chunk of data access you want to perform.

I've only used the EF in ASP.NET MVC apps and I followed the suggested path of creating a repository class that creates an instance of the entities collective. If I was going to use it in a Windows app I'd follow a similar pattern and all the data access would take place in that repository, facilitating use in any n-tier system.

[Pino]

It's not necessarily a great idea to have a single static instance like that. It will end up growing with each data access and keeping data around that you don't need any more. You should actually create a new instance for each chunk of data access you want to perform.

I've only used the EF in ASP.NET MVC apps and I followed the suggested path of creating a repository class that creates an instance of the entities collective. If I was going to use it in a Windows app I'd follow a similar pattern and all the data access would take place in that repository, facilitating use in any n-tier system.

Thanks for the reply, could you expand on that a little more? This is a web-app, where the Entites object is in an external lib, I want to keep as much of the database interaction as possible in the lib.

[jmcilhinney]

You might want to take a look at the example they provide on the official ASP.NET MVC site.

http://www.asp.net/learn/mvc/tutorial-29-cs.aspx

That's iteration 4 of their example app, where they refactor out the repository, which is probably of most interest to you. You might want to start at the first iteration for completeness though.

[gep13]

Hey jm,

That is a very nice article, hadn't seen that one before!!

Bookmarked :)

Thanks

Gary

[Pino]

Hey jm,

That is a very nice article, hadn't seen that one before!!

Bookmarked :)

Thanks

Gary

Thanks will check it out, I didnt really any intention of using MVC but it seems that the more I look the more MVC shouts at me.

[jmcilhinney]

Yeah, I've never really got into web development because, I have to admit, I never really liked web forms. It felt like it was trying to be like WinForms in an environment that just didn't support it, which is pretty much exactly the case. That's not really a criticism of Web Forms per se, but MVC just feels far more natural to me for web development so, even though it's far more different to my usual WinForms than Web Forms is, I actually feel more at home with it because it just seems to suit the web. I'm far from an expert in its use but we're about to embark on a big project at work that is based on MVC so I should be more familiar with after that.

That said, you can still implement that Repository pattern to wrap your Entity Framework classes no matter whether the app is MVC or not. The idea would be that that same data access layer could be used in any application at all.

[Pino]

Is there a downside to this, I've expanded the generate Product class and added the 4 most common methods.


public partial class Product
{
private DBEntities _entities = new DBEntities();

public Product GetProduct(int id)
{
return (from c in _entities.Product
where c.Id == id
select c).FirstOrDefault();
}


public IEnumerable<Product> ListProducts()
{
return _entities.Product.ToList();
}


public Product CreateProduct(Product ProductToCreate)
{
_entities.AddToProduct(ProductToCreate);
_entities.SaveChanges();
return ProductToCreate;
}


public Product EditProduct(Product ProductToEdit)
{
var originalProduct = GetProduct(Convert.ToInt32(ProductToEdit.Id));
_entities.ApplyPropertyChanges(originalProduct.EntityKey.EntitySetName, ProductToEdit);
_entities.SaveChanges();
return ProductToEdit;
}


public void DeleteProduct(Product ProductToDelete)
{
var originalProduct = GetProduct(Convert.ToInt32(ProductToDelete.Id));
_entities.DeleteObject(originalProduct);
_entities.SaveChanges();
}

}

[jmcilhinney]

It's probably not appropriate to extend the Product class like that. Now you're mixing the functionality of a product with the functionality for working with products. They are two different things and belong in two different classes. The data access code should be separate to the data that it's accessing.

[Pino]

Ok thanks for your help with this. So I've changed that now to be a seperate 'Controller' class we I can use to include the standard CRUD methods. This seem to be quite extensable now. DO you have any other suggestions in terms of structure?

[Pino]

Ok carrying on from above I've attached a template structure, you wont be able to run the project as the database isnt attached (There is only 1 table - Product anyways). But I'd like to get some thoughts on architecture.

[jmcilhinney]

Please ensure you delete all 'bin' and 'obj' folders before zipping up a project in future as it's against site rules to post binary files.

With regard to nomenclature, if you do think you might end up going with MVC then you'll have to change the name from ProductController to something else, most likely ProductRepository. The controller has a different role in MVC and the repository classes are part of the model.

The other point to note is that I'd tend to have a member variable store the DedimiEntities instance so that each ProductController, or whatever it ends up being called, has one and only one instance of the DedimiEntities class. I'd then create new instances of the ProductController class as and when needed.