Is it possible to mock an EF model so that I can test code which uses the model classes without getting rid of LINQ to Entities code strewn throughout my project? Or will it be necessary to set up a test database for the model to hit instead?
You could wrap your LINQ code in Data Access Objects. The DAOs would have separate interface and implementation code. Your test code would mock the DAOs.
If you don't want to do that, you'll need a test DB.
Related
I know entity framework designer is used to create the classes of model-first approach and then we create the database by using that class. But in code-first appraoch, it is possible to create the custom classes, within that classes the database is created automatically. Then what is the difference between code-first approach and model-first approach?
Code First is the more modern style of working with Entity Framework. As the name implies, you write the code first and the database model is generated for you, by using Entity Framework Migrations. In this scenario you are not using any graphical tool at all, everything is just pure code.
Model first means creating the abstract database model in the designer. The code is then generated by templates. If you update the model, the code will be regenerated.
I'm creating some test using ms test for an already written routine that use entity framework, and I would like to use the [DataSource] attribute to generate a test routine for a set of data in the database.
My problem is that I can just select a Table and load the single fields in the test, but I would like to fetch directly a set ob ef entities and process directly in the test routine, in a way much more similar to the way the code to test is wrote.
Exist some kind of [EFDatasource] that let me express a Ef query as datasource and use the entity in the test?
thanks,
luca
You should just use a context instance (or service/repository, what have you) in your unit test method and get the entities from it. You can supply the connection string in a config file in the unit test project. This way the test methods will be totally relieved from any connection worries. They just instantiate objects and work with them.
Some will probably comment that this is not unit testing but integration testing and that you should mock the EF context, but that is virtually impossible. Testing EF should be done with... EF.
In my project, I need to use EF and abstract the queries from the Presentation layer. Based from what I've been reading questions and answers all over the net, EF is built having repository pattern on it's DbSet and Unit of work on DbContext.
Repository pattern can easily do the requirement but I don't wanna repeat this implementation and now confused where should I initialize or access the DbContext. Should it be on the service layer?
MVC4 Api will be used for this project
One way I have seen this done in the past is to essentially remove the DbContext's dependency on a physical database by creating an interface for your context then make your data access calls from your Services Layer (Business Logic Layer).
There is however, a disadvantage in using this approach, which is the fact that your unit tests (which will be using a Fake implementation of your DbContext) will be using LINQ to Objects to run your queries whereas your concrete implementation will use LINQ to Entities which does not support all LINQ to Objects methods.
There's documentation on MSDN (http://msdn.microsoft.com/en-us/library/bb738550.aspx) which highlights these differences.
I also recommend reading this article (http://kearon.blogspot.com.au/2011/02/mocking-entity-framework-4-code-first.html) which demonstrates how to make DbContext unit testable by removing the inderlying dependency on a phyiscal database.
Hope this all helps!
EF and ORM.
I recently realized that is possible using POCO to have clean classes not plumbed with EF auto generated code.
I saw the new release of EF 4.1 and the use of Code First approach and DbContext.
My questions:
What is the difference between Code First approach and Poco approach?
Can we use Code First (DbContext and DbSet) instead of POCO + Repository pattern?
Thanks for your time on this.
They're completely different things, and you can use them together.
POCO means that your entity classes are "normal" classes, not dependent on any specific ORM layer.
A DbContext is an object that enables you to access the database in an object-oriented way (like ObjectContext in earlier versions of EF).
Have a look at this tutorial for examples.
We are in a process of designing an application with approx 100 tables and complicated business logic. Windows Forms will be used on the client side and WCF services with MSSQL on the server.
Custom DTOs are used for client-server communication, business entities are not distributed.
Which variant of Entity Framework to use (and why):
EF 4.0 EntityObjects
EF 4.0 POCO
EF 4.1 DbContext
Something else
Database-first approach is a requirement.
Also, is it worth implementing a Repository pattern? It seems a bit redundant, as there is one level of abstraction in the mapping itself and another one in the use of DTOs. I'm currently leaned towards using auto-generated extendable repositories for each entity returning IQueryable, just to have a place to put common queries, but still allowing querying entity model directly from the Service Layer.
Which variant to use? Basically once you have custom DTO the only question is do you want to have control over entities code (their base class) and make them independent on EF? Do you want to use code first? If the answers to all questions are no then you can use EntityObjects. If you want to have entities persistence ignorant or use custom base class you should go to POCO. If you want to use code first or new DbContext API you will need EF 4.1. Some related topics:
EF 4.1 Code-first vs Model/Database-first
EF POCO code only VS EF POCO with Entity Data Model (this was related to CTP)
ADO.NET DbContext Generator vs. ADO.NET POCO Entity Generator
EF Model First or Code First Approach?
There are more things to consider when designing service layer. You should be aware of complications you will have to deal with when using EF in WCF. Your service will provide data to WinForms application and it will work with them in "detached mode". Once user will do all changes he wants to do he will post data back to the service. But here comes the problem - you must tell EF what has changed. If you for example allow user to change order with all its order items (change quantity in items, add new items, delete some items) you must say EF exactly what has changed, what was added and what was deleted. That is easy when you work with single entity but once you allow user to change object graph (especially many-to-many relations) then it is quite tough. The most common solution is loading the whole graph and merge the state from incoming DTOs to loaded and attached graph. Other solution is using Self tracking entities instead of EntityObjects/POCOs + DTOs.
When discussing repositories I would refer you to this answer which refers many other answers discussing repositories, their possible redundancy and possible mistakes when using them just to make your code testable. Generally each layer should be added only if there is real need for the layer - due to better separation of concerns.
The main advantage of POCOs is that those classes can be your DTOs, so if you've already got custom DTOs that you're using, POCO seems a bit redundant. However, there are some other advantages which may or may not have value to you, since you didn't mention unit testing as a requirement. If you plan to write unit tests, then POCO is still the way to go. You probably won't notice much difference between 4.0 POCO and 4.1 since you won't be using the code-first feature (disclaimer: I've only used 4.0 POCO, so I'm not intimately familiar with any minor differences between the two, but they seem to be more or less the same--basically I was already using POCO in 4.0 and haven't seen anything that's made me want to update everything to use 4.1).
Also, depending on whether you plan to unit-test this layer, there's still value in implementing the repository/unit of work patterns when using Entity Framework. It serves to abstract away the data access logic (the context), not the entities themselves, and allows you to do things like mocking your context in unit tests. What I do is copy the T4 template for my context and use it to create the interface, then edit the T4 template for the context and have it implement that interface and use IObjectSet<T> instead of ObjectSet<T>. So instead of:
public class MyEntitiesContext
{
public ObjectSet<MyClass> MyEntities
...
}
I end up with:
public interface IMyEntitiesContext
{
public IObjectSet<MyClass> MyEntities;
}
and
public class MyEntitiesContext : IMyEntitiesContext
{
public IObjectSet<MyClass> MyEntities
...
}
So I guess it really comes down to whether or not you plan to write unit tests for this layer. If you won't be doing anything that would require mocking out your context for testing, then the easiest thing to use would probably be 4.0 EntityObjects, since you aren't planning to pass your entities between layers and it would require the least effort to implement. If you plan to use mocking, then you'll probably want to use POCO and implement repository/unit of work.