I am trying stuff out on MVC4 Beta. Project is in VS11, EF 5.0-Beta, using Code First approach.
Created simple Model poco and DbContext derived class with single IDbSet<> property for model class. Connection string with LocalDb.
I noticed when context's Entity Set property is type of IDbSet<> then I get message from VS when I try to create new controller with “Controller with read/write actions and views, using Entity Framework” Scaffolding template:
"There was an error generating 'MyProject.MyNamespace.MyContext'. Try rebuilding your project."
Even Clean Solution and building again doesn’t help.
If I changed Entity Set property to type DbSet<> then controller scaffolding succeeds.
Is it a bug or is it expectable?
Br,
Lauri
It is not a bug you cant instantiate an instance of an Interface. The I in front of IDbSet denotes the type as an interface (By convention). So you were trying to create an instance of that interface. Instead you need to delcare it with DBSet<> which is an implementation of the IDBSet<> interface. I hope this clarifies your issue.
Related
I am currently getting the warning in Grails of
'The [update] action accepts a parameter of type [edu.acu.teachereval.SubjectCode] which has not been marked with #Validateable. Data binding will still be applied to this command object but the instance will not be validateable.
#Transactional'
along with the same errors for show, save, edit, and delete for the controller mentioned in the error and other controllers that I have created. I have seen this issue for user created functions, but I have not seen this error for functions that are built in to grails. Any assistance would be appreciated.
I think you need to add a #Validateable annotation to your SubjectCode class.
Reference
This may be coming late, But this error is likely to occur when you use models not created in the domain conventional folder.
It seems grails automatically injects the #Validateable annotation to domain classes/models in the domain Folder,
If you therefore create your models in the src/grails or src/java folder, You are likely to get this error when the model object is passed/posted/submited via a View to a controller function.
Try adding the #Validateable annotation to the domain object
Move the domain model to the domain grails convention folder
or maybe Grails is overreaching while simultaneously giving misleading error messages... nah, that never happens. For a more relevant answer, see:
Groovy / Grails using a map as a parameter of a function
When using EntityFramework and returning an IQueryable from an MVC 4 Web API Get action, the following error occurs when the XML serializer is set to use the old XmlSerializer (rather than DataContractSerializer).
XmlMediaTypeFormatter cannot write an object of type ObjectQuery
Is this a known issue?
Too late for this question but for those who faced the same exception:
Your ObjectQuery class probably lacks a default constructor.
See my full answer here: Xml Serialization cannot write an object of type 'x'
No.
You need to define [Queryable] attribute on your action. This requirement was added on RC and probably will be removed at RTM
NOTE
OData support is very unclear at the moment. I have created PocoHttp for consuming ASP.NET Web API's OData but paused development because of lack of clarity at the moment.
I had this error because one of the members of the class I was serialising was an interface. I didn't need to serialise that member so annotating it with a [XmlIgnore] attribute fixed it.
My original project is in Asp.net MVC 2.
I convert my project to MVC 3 without problem.
In the same time, I install the EntityFramework 4.2. Again without problem.
Were it's begin to be complicated is when I add the T4 Generate DBContext.
Thats create me the T4 properly and generate all my entity into his own "POCO Class". Thats perfect!.
When I Build my project, I Got about 400 error. Here is some example.
'mvn.Models.DBEntities' does not contain a definition for
'AddToLeaseConditionInfos' and no extension method
'AddToLeaseConditionInfos' accepting a first argument of type
'mvn.Models.DBEntities' could be found (are you missing a using
directive or an assembly reference?)
As you can see here, the context.AddToLeaseConditionInfos(objCondition); doesn't work anymore.
Same for the DeleteObject context method.
context.ConvertionUnits.DeleteObject(MyObjConvertionUnit);
Someone has an Idea.
Thanks a lot.
You previously used ObjectContext API and default code generator (or EntityObject T4 template) but now you are trying to use DbContext API with POCO DbContext T4 Generator. Those two are completely incompatible because they represent different API. You must use the same code generation approach as you used in EFv4 (which means upgrade will not give you almost any additional value) or you must rewrite your current data access code to use new API.
This is pretty much a duplicate question but instead of using Castle Dynamic Proxy I'm using LinFu Getting underlying type of a proxy object
I'm using automapper to create proxies of interfaces that I'm sending to my viewmodel in Asp.net MVC. My problem is from what I can tell that MVC's default MetadataProvider find the properties and metadata by calling .GetType() on the model.
So what happens is EditorFor() and DisplayFor() templates don't generate any fields. What I need to do is find the proxy target type and then generate my templates. I know I can just parse the name and use GetType( "thename" ) but was wondering if there was an easy way.
LinFu.DynamicProxy doesn't directly expose the underlying object of a proxy. It simply redirects each method call to an IInterceptor implementation instance. In order to access the underlying object, you'll have to figure out whether or not the current interceptor instance actually has a target class instance, or not.
If you're working with AutoMapper, AFAIK, they use LinFu.DynamicObject to do a lot of the duck taping, and calling GetType() on a dynamic type generated by LinFu.DynamicObject won't even get you the actual type in your domain model--it will just get you an object that has been literally duck-taped together by LinFu itself.
get latest AutoMapper - it uses Castle Dynamic Proxy, and you already know how to get this from there :)
Greetings,
Trying to sort through the best way to provide access to my Entity Manager while keeping the context open through the request to permit late loading. I am seeing a lot of examples like the following:
public class SomeController
{
MyEntities entities = new MyEntities();
}
The problem I see with this setup is that if you have a layer of business classes that you want to make calls into, you end up having to pass the manager as a parameter to these methods, like so:
public static GetEntity(MyEntities entityManager, int id)
{
return entityManager.Series.FirstOrDefault(s => s.SeriesId == id);
}
Obviously I am looking for a good, thread safe way, to provide the entityManager to the method without passing it. The way also needs to be unit testable, my previous attempts with putting it in Session did not work for unit tests.
I am actually looking for the recommended way of dealing with the Entity Framework in ASP .NET MVC for an enterprise level application.
Thanks in advance
Entity Framework v1.0 excels in Windows Forms applications where you can use the object context for as long as you like. In asp.net and mvc in particular it's a bit harder. My solution to this was to make the repositories or entity managers more like services that MVC could communicate with. I created a sort of generic all purpose base repository I could use whenever I felt like it and just stopped bothering too much about doing it right. I would try to avoid leaving the object context open for even a ms longer than is absolutely needed in a web application.
Have a look at EF4. I started using EF in production environment when that was in beta 0.75 or something similar and had no real issues with it except for it being "hard work" sometimes.
You might want to look at the Repository pattern (here's a write up of Repository with Linq to SQL).
The basic idea would be that instead of creating a static class, you instantiate a version of the Repository. You can pass in your EntityManager as a parameter to the class in the constructor -- or better yet, a factory that can create your EntityManager for the class so that it can do unit of work instantiation of the manager.
For MVC I use a base controller class. In this class you could create your entity manager factory and make it a property of the class so deriving classes have access to it. Allow it to be injected from a constructor but created with the proper default if the instance passed in is null. Whenever a controller method needs to create a repository, it can use this instance to pass into the Repository so that it can create the manager required.
In this way, you get rid of the static methods and allow mock instances to be used in your unit tests. By passing in a factory -- which ought to create instances that implement interfaces, btw -- you decouple your repository from the actual manager class.
Don't lazy load entities in the view. Don't make business layer calls in the view. Load all the entities the view will need up front in the controller, compute all the sums and averages the view will need up front in the controller, etc. After all, that's what the controller is for.