Vibrant discussion about CSLA .NET and using the framework to build great business applications.
I am pretty new to CSLA and I am trying to introduce a BL on top of the already built DL.
The DL is build using EF4.3 and the DBContext. I am starting to face some challenges but I am not sure whether it's due to a bad implmementation or an inherent incompatibility between the tools I am using.
In particular, I have this one case that is causing a lot of trouble. I have a Location BO that has a child State BO. These two BOs belong to different BLs. State class is defined in another dll and uses a separate DL to access a separate database.
The problem happens when I try to populate the child State object. For some reason the dbcontext in the State DL stops being able to recognize the State class and I get the error message "The entity type State is not part of the model for the current context.".
This is how the Fetch operation for the Location class looks like:
private void DataPortal_Fetch(int id)
DTO.Location dto = DTO.Location.GetByID(id);this.ID = dto.ID;
And this is where the exception happens (in the State DL when exexuting the query below):
public static State GetByID(int id)
using (GB2_Entities1 context = new GB2_Entities1()) return context.States.SingleOrDefault(b => b.ID == id);
(Sorry for the horrible code format, but I wan't able to format it properly)
I found what was causing this issue just yesterday. My problem was that there were serveral EF models with the same name in various projects in the solution. Whenever two of these models are referenced in a project, a problem will happent because apparently this project will have a porblem looking up the correct model for each class.
I solved the issue by giving all EF models in the solution different names.
I am actually using CSLA with EF Database First.
Csla is compatible with any ORM including EF CF (Code First). I've gotten that error before from EF CF when trying to save an entity in a different context that was created. You can google for that error, doesn't really have anything to do w/ CSLA. However, I believe what you will end up having to do is implementing a way to manage the context similar to the built in manager for EF w/ ObjectContext. Others may be able to help, I haven't used CSLA in a while.
One thing I am curious is why you are using EF CF w/ CSLA? It seems like a lot of work creating your EF CF Pocos by hand and then create the CSLA BO's as well. Part of the "appeal" of EF CF is to create your own POCO "domain" classes, but CSLA already gives you that...would make more sense if you were using CSLA w/ EF Database First / Model First rather than Code First.