Im using the entity framework 4.1 and have followed a tutorial to fake the dbcontext to mock and do unit tests. Everything works as expected with this. ive amended the original dbcontext to return idbset's however when i recreated my model it overwrote this. This is to be expected i suppose but wondered whether there is away i can stop this happening. Any ideas?
Probably the easiest approach is to replace the T4 templates that do the code generation with your own – copy the default templates into your project and adapt them to generate the code you want.
MSDN has an introduction: http://msdn.microsoft.com/en-us/data/gg558520
You can also use moles. But I like the t4 template better.
Related
I'm a new comer to the Scaffold world to build repositories creating the CRUD operations.
There are a lot of scaffolding templates ,I'm so confused which one will suit my requirement .
I use asp.net web forms (not asp.net MVC)
I use Entity Framework 6 as ORM .
I want some help to clarify the main pillars we select one scaffolding template over one and what's the proper one for my case ?
NOTE : Right now i use T4Scaffolding .
I think you can use T4Scaffolding, as you already do. But why are you using a "scaffold"? I created my crud app with entity framework without scaffolding anything.
Anyway, the scaffolding tools are all very similar, so T4Scaffolding is perfect, IMHO.
I think you can find interesting this and this.
Let me know if you have other questions.
It looks like you are trying to generate repositories for each model class. If that's the case, my advice will be don't. Moreover, don't be tempted by Generic Repositories (anti-pattern) as well.
For Scaffolding
If you must use scaffolding for generating repositories around your model classes, you may refer to this link for scaffolding repositories using T4Scaffolding.
Note:
If you're using Visual Studio 2013/2015, you would have to use the T4Scaffolding.VS2015 nuget package instead of the older T4Scaffolding package (for older versions of VS).
Aggregate Roots
Firstly, repositories are created on aggregate roots and not per class.
Secondly, although debatable, but EF already implements these patterns.
You many want to read more on repositories; refer t the Matrin Fowler's excellent post.
Why Use Repositories anyway?
Also, there are a bunch of people against it as well importantly for good reasons.
See Rob Conery's post on it. Although, I would prefer using the below solution instead of the one recommended in the post.
The alternate?
BTW, you should consider using commands or tasks instead of respositories. Something like Ayende's post. Of course, you should evaluate your case and come up with your reasons to adopt it. It's just a suggestion, probably a good one ;)
In my project, I trying to implement repository pattern and unit of work.
I found some web site to describe how to implement it such as:
http://www.codeproject.com/Articles/688929/Repository-Pattern-and-Unit-of
http://www.codeproject.com/Articles/561584/Repository-Pattern-with-Entity-Framework-using
I was wondering, why is not generic Unit of Work and Repositories Framework? then try several search on internet and I found it,
http://genericunitofworkandrepositories.codeplex.com/
This framework is first code but my project is model first therefore is not work correctly?
Could you please suggest me model first framework like this?
My project is a internet web site with one database, If there is plausible reason I can change model first approach to code first approach.
Thanks for you time.
We've abstracted all the interfaces in our latest release into Repository.Pattern project https://genericunitofworkandrepositories.codeplex.com/SourceControl/latest#main/Source/Repository.Pattern, in plans to implement nHibernate provider. You are more than welcome to start implementing these interfaces, based on bandwidth at the moment, I cannot commit to any dates as of yet.
I'm relatively new to EntityFramework and really want to get into testing things before I get too much further into things and have a huge codebase to retrospectively write tests for. I've not used it much and so methods are fairly basic, like below;
public Employee GetEmployee(int employeeID)
{
using (DatabaseContext db = new DatabaseContext())
{
return db.Employees.SingleOrDefault(e => e.idEmployee == employeeID);
}
}
This is fine in my app, but in my test project, it doesn't work because the test project doesn't seem to read the app.config file and so there's no connection string for DatabaseContext to use. I've read a bit about testing, nothing seems really definitive, though this post is the "official" way to do things (it's linked to from MSDN. The post seems fairly involved though and would require me to do things a lot differently than what I currently am, unless I've misunderstood some of it?
Could someone help clear this up for me? I can't even cheat and copy app.config across to the test project, it still doesn't read it (I've also tried renaming to MyApp.exe.config and still no luck). Is my GetEmployee method wrong? Should I do something more like the linked post? Or is there some way to test that I've not found yet?
#FizzBuzz - here is another article the discusses how to setup your unit test projects to work with entity framework:
How to get Entity Framework to read my app.config file in Unit Test project
You can read one approach for integration testing here.
About the config issue setting Copy to Output Directory property to Copy Always should do the work.
There are to options to resolve the issue you are facing.
Option 1: Create a mock for the app.config values. for mocking you can use Rhino Mock
Option 2: In your Unit Test project : Right click on the project > Add > Existing Item >
Select File > Add it as a link.
If you don't want to go with your live database (and right so!), then you basically have two options:
Use another database (must be of the same kind as your live db,
since EF doesn't allow for changing the db system, only its
location) and add another app.config to your unit test project
(which is the same as in your live project except that the db
connection string is different).
Use the NDbUnit framework, which
allows for defining the data in xml files. Here also you'll need an
individual app.config for your test project, if you don't want to hardcode the test data connection string. (This approach is only
advisable, if your live db has no or only very few schema changes,
because NDbUnit is quite allergic to these.) I wrote a blog post (with sample solution) about this approach here.
A third approach would be to mock all EF stuff, but this quickly gets overly complicated (you can find this also in a previous part of the above mentioned post, if you're interested).
HTH
Thomas
Thanks for the information people, found some interesting hints and tips through the various links supplied. In the end, I tried out this article from MSDN, funnily enough! Though it says it's for EF6, it does actually work for previous versions. The reason it indicates EF6 is for async stuff.
FxCop analysed the auto-generated code in edmx files...
This bug is already known: Mircosoft Connect.
The only solution proposed there is from 2010 Customizing the Entity Framework T4 Template, suppressing code analysis.
Do you know some better solution or workaround for this problem?
You could try using the DbContext templates instead of ObjectContext.
More info:
DbContext was introduced in EF 4.1 as part of Code First and since EF5 has also become the default generated context for Db/Model-first approaches. It uses POCO entities and simplifies a lot of common tasks, which I find makes my model easier to maintain. It also wraps ObjectContext, so you can still call into that if you need to. Since it generates different code, you'd be avoiding the FxCop warnings you are currently seeing, but of course switching to DbContext would require changes to your application code.
I'm using Entity Framework 5 in my project. And I wanted to test some new funcionalities.
What happened is that eventhough my db is UPDATED, (when I add a migration it does not add anything else) and eventhough if I run my project it runs just fine. When I try to test the project with NUNIT I get this exception:
System.InvalidOperationException : The model backing the 'DbContext' context has changed since the database was created. Consider using Code First Migrations to update the database
Has any of you have this problem? If so how can I solve it?
Well, my original answer got deleted, guess because it wasn't really an answer as much as a statement that I had the same problem. At this point I have found an answer of sorts, so maybe this one will pass muster.
Of course, I only assume we are having the same issue, but it seems pretty likely since the symptoms are exactly the same. What I discovered is the connection string for my repository was not getting set correctly even though I had set it up "correctly" in a config file using the MyTestProject.dll.config naming convention. Seems like NUnit isn't using the connection string from the config for some reason.
I've set up a temporary solution where I use a different constructor that forces the correct connection string for my repository when creating it for NUnit. Easy to implement this since I'm using DI to create the repository and just need to ask the factory for a different flavor when testing. Working now to figure out why NUnit doesn't use the config file as it seems like it should.
Maybe not a complete answer, but at least this solution got me back to where I can test... We'll see if this one gets deleted.