locked
What is the best design pattern to use with EntityFramework RRS feed

  • Question

  • User-807215970 posted

    What is the best design pattern to use with Entity Framework? is there any open source projects or examples to follow?

    Thank in advance

    Wednesday, February 11, 2015 2:22 PM

All replies

  • User-821857111 posted

    What do you mean by "best"?

    Wednesday, February 11, 2015 2:28 PM
  • User-807215970 posted

    best for separating business logic from database and need less code to implement with entity framework. 

    Wednesday, February 11, 2015 3:19 PM
  • User-1611549905 posted

    No design pattern is going to give you a total separation of business logic from the database. Some design patterns claim to be able to do so, but on closer inspection, what they do in reality is either move business logic into the DAL or else severely restrict you from making full use of Entity Framework's features (some of which are important, especially for performance reasons). However, that doesn't mean to say you should mix your concerns up with complete abandon.

    In general, you should let your separation of concerns be driven first and foremost by your unit tests. You can (and should) mock Entity Framework itself in order to test your business logic without hitting the database as far as possible. A good way to do this is to use Query Objects, which take either an IQueryable<T> or an IDbSet<T> depending on whether they also need to call .Include() to specify fetch paths. For simpler queries, you can use extension methods on IQueryable<T> or IDbSet<T> instead.

    Don't be too strict about not hitting the database though: there are some things that you can't test without doing so. In particular, if you need to test that you are making the right calls to .Include(), or if you need to test that your particularly complex LINQ query is supported by Entity Framework (some of them aren't), you will need to hit the database.

    Two other things: first, put your business layer, your data access layer and your models in the same project. Splitting them up into different projects just generates friction and complexity without delivering any real-world benefits whatsoever. Second, don't attempt to speculatively make your data access layer swappable for another implementation. Swapping out Entity Framework for a web service or something is much more complex than many people expect, and should only be attempted if you know up-front what other data sources you need to support and can develop and test against both or all of them from the outset.

    Wednesday, February 11, 2015 8:21 PM
  • User-1067017023 posted

    best for separating business logic from database and need less code to implement with entity framework.

    Just don't put business logic in your data access code, simple! You don't need a design pattern for that, anyway entity framework wouldn't pull in any business logic by itself.

    Thursday, February 12, 2015 12:33 PM
  • User-1611549905 posted

    Just don't put business logic in your data access code, simple!

    If only it were that simple. Unfortunately, as I keep saying, it isn't always possible to classify code as one or the other.

    Take queries for example. I am constantly seeing queries being classified as data access code. This may well be the case, if they can't be tested without hitting the database. But they are also business code, because they implement business rules and they are covered by tests that verify the correctness of business rules.

    IQueryable<T> and IDbSet<T> give us an API that can introduce a certain amount of separation between the two in many cases, but it's not perfect: calls to .Include(), NotSupportedExceptions when you try to make your queries too complex, and necessary performance optimisations introduce a certain amount of tight coupling that it's simply not possible to avoid.

    Thursday, February 12, 2015 1:15 PM
  • User1689970273 posted

    Here are your guidelines creating Entity Framework.

    1. Create a blank solution.

    2. Create a DAL Project, Model Project, Create a unit project, create a mapper project, create core project, DI Core Project, Validation Project,asp.net mvc project etc.

    3. You may organize it as a folder afterwards.

    The most important project are your model project and DAL project.

    Model Project will just consist of plain Model which represents your DDD.

    Your DAL will have a possibility of repository and service pattern (interface and implementation).

    A database context which you will inherit from DbContext,   Possible generic db context so you can actually define entities,

    You will a separate entitytypeconfiguration table per model as needed

    From here, you should be able to run the EF commands: enable-migrations,add-migration, update-database  with -script (to generate sql script) <---rollback any bad coding....

    Mapper will consist of your AUTOFAQ/AUTOMAPPER  whenever you have

    Core will have all references of all or some of your projects...

    In this way, DAL and Model are already testable without other projects.

    To test:

    1. Test the DatabaseContext directly (all CRUDS)

    2. Test it with repository

    3. Test it with service layer

    4. Test it with validations (positive and negative)

    Hope this helps.

    Tuesday, February 24, 2015 2:46 PM