CODEWITHSUNDEEP
c#entity-framework
james
james

Reputation: 1041

EF6 and business logic layer

I'm trying to get a grasp of using the EF for an upcoming project.

Currently I have this code first code:

public class Blog
{
    public int BlogId { get; set; }
    public string Name { get; set; }

    public virtual List<Post> Posts { get; set; }
}

public class Post
{
    public int PostId { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }

    public int BlogId { get; set; }
    public virtual Blog Blog { get; set; }
}

public class BloggingContext : DbContext
{
    public DbSet<Blog> Blogs { get; set; }
    public DbSet<Post> Posts { get; set; }
}

This created the database and tables and I've been able to add blogs / post no problem. But I am confused about how to structure around EF code first approach.

Should both Blog and Post have a reference to BloggingContext and then have their own get / add / update methods ?

Should I create separate BlogManager / PostManager classes that actually do the getting / adding / updating of data and simply return the entity objects?

Should I create separate classes that inherit from Blog / Post that contain the get / add / update methods?

Upvotes: 1

Views: 618

Answers (2)

D Stanley
D Stanley

Reputation: 152501

Should both Blog and Post have a reference to BloggingContext

No - the classes themselves should not be tied to a particular source. They should just represent an entity and be independent of where the data comes from. That allows for easier unit testing since you can create a blog that is completely independent of your data source.

Should I create separate BlogManager / PostManager classes that actually do the getting / adding / updating of data and simply return the entity objects?

Yes - this is typically called a repository, so BlogRepository and PostRepository might be better names.

Since the two will be inter-dependent it would also be good to create IBLogRepository and IPostRepository interfaces that the repositories implement so you don't tightly couple the repositories. Then when you query for a blog and want it's post as well the BlogRepository can chain the request to the IPostRepository.

Should I create separate classes that inherit from Blog / Post that contain the get / add / update methods?

No - because inheritance implies an "is a" relationship - and a class that saves a blog it not necessarily a blog itself.

Upvotes: 1

Corey Adler
Corey Adler

Reputation: 16137

The DbContext class can handle everything data-related on its own. You don't need to include a reference to them in your entity classes (nor should you, since DbContext classes open up a database connection). DbContext will also handle your basic CRUD operations on its own (through the use of the DbSets<T> on it, which are easy ways to access all of the data in a specific table.

If you want, you could also do what @Sergey mentioned above in the comments and implement a repository interface on top of it. I have written a blog post about doing that which you can find here. Basically, you set it up as a generic repository with a background reference to the DbContext class, and in that way you can put up a nice layer in between your application code and your database logic.

Upvotes: 1

Related Questions