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.
Related
Our legacy application is using EntitySpaces for database access but since ES is EoL for several years and is causing some performance issues on our application we're thinking about switching over to EntityFramework.
Is there an easy way to do this without completely rewriting all of our extension classes?
EntitySpaces is alive again and the API has been updated and is far more streamlined. It's a single DLL Nuget install too. What kind of performance issues, I'd love to hear about the issues
https://mikegriffinreborn.github.io/EntitySpaces/
I've been thinking about this for a while. I don't think there is going to be a simple solution to move away from EntitySpaces and move to EntityFramework. But the approach I would, and probably eventually will take, is if you haven't already, add an interface to each of the methods in your Business logic that inherits from the data classes and include every method you need.
Now, add a Database First EF model and create new business-logic classes for each entity/model to inherit from that interface you've made. Then you know every method that requires re-writing in EntityFramework(LINQ/Lambda). It's a slow process but this way you can do the migration over multiple release windows, slowly moving everything over, referencing the new EF business-logic models as-and-when you have time (and of course, any new tables can use EF straight away).
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 ;)
I generated a database first ObjectContext using EF 4.3 in VS 2010. Then I used this class (and relating classes) in a Windows.Forms application.
This time want to use the same application with minor additions to some forms and an additional table (and a FK to it) to create a new application. Since I want to manage both projects at the same time, I created a new solution for second application, which subclasses the necessary forms and classes.
But I don't know how to use this technique for the ObjectContext I generated before. If I use an automatically generated new ObjectContext this will be a new class, therefore I have to recompile all the two solutions whenever I apply a change (I don't even mention the necessary assembly reference changes).
Manually creating a subclass of the aforementioned ObjectContext is not possible I guess if I don't do csdl/mdl/ssdl tricks manually.
I want to avoid creating an interface class between my code and the ObjectContext, because of the changes needed and lack of time to achieve.
Does anybody have an idea?
It seems like you misunderstanding some concepts in software development process.
This:
Since I want to manage both projects at the same time, I created a new
solution for second application, which subclasses the necessary forms
and classes
is a very bad idea.
In fact, new functionality brings you to new version of your software.
Do not inherit anything. Just make a development branch (in terms of source control) for your previous project version, and continue to develop new version, extending functionality.
This will allow you to get two, completely independent versions of your software, which you will support simultaneously.
Just trying to confirm an impression: it seems enums in EF5 + Code First are only supported when declared within the same namespace as the classes using them as property types.
Can anyone confirm that? Couldn't find anything on the web for this...
A relevant bug that was fixed earlier. 4.3 Beta 1 release notes say:
Bug fix for GetDatabaseValues. In earlier releases this method would
fail if your entity classes and context were in different namespaces.
This issue is now fixed and the classes don’t need to be in the same
namespace to use GetDatabaseValues.
My guess is that GetDatabaseValues function is still buggy for this occasion (but that's just an educated guess). You may want to report this here: ADO.NET team blog: EF5 Beta 1 Available
Not only do your enumerations have to be in the same namespace to be supported by EF5 Code First, they have to be in the same class file as your POCO Model.
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.