I am in a process of developing an N-Tier solution for which I am using Entity Framework (4.X) DB first approach with ADO.Net Self Tracking entity in Repository layer. I have MVC WebAPI project and Breeze configured there. I have breeze client also configured in a seperate MVC UI project. The communication between Breeze client and server seems to work fine except that there are no Entity Ness like entityAspect object on client side after the query executes and resuls are returned.
When I change from ADO.net Self tracking entity to normal ADO.Net entity, everything seems to work fine i.e., entityAspect gets created correctly. So, just want to know if there is support in Breeze for the Self Tracking entities or not?
My Dev configs. are VS 2010 & MVC 4. I know these are bit old but client does not have license for the newer versions at the moment.
Related
My web application in ASP.NET uses Angular as its frontend. For database and API, I made 3 projects in the solution. API, BOL and Entity Framework.
BOL has all the POCO classes.
Entity Framework has the DbContext class and the connection string to the SQL Server database. It also has the reference to BOL. All the repositories with insert, update, delete and get methods for every entity are there too.
API has the API controllers with crud functionality which call the methods from the Entity Framework project. It has a reference to Entity Framework project.
But when I try to call a method from Entity Framework on the instance of the respective repository, it asks to add reference to BOL. But it should not use BOL as that ruins the purpose of the Entity Framework project
it depends how you are using the POCO classes.
if the EF project uses POCO classes to return results and your API calls methods inside the EF project then you will need a reference to BOL because otherwise the API project doesn't know how to deal with the results.
The fact that both the EF and the API project have references to BOL is not an issue, it's exactly as it should be, since both use these models and that's why you separated the models in the first place. You want them to be shared.
So bottom line, if the EF projects takes input or returns data using the BOL classes then you need to add a reference to that project in your API project.
Now, for the second issue with the connection string having to be in the API project, that will have to stay that way. The reason is because of how the framework works.
You have a main project and you reference a class library. When you compile the solution, the EF dll get built and copied over to the API project. At that point it will use the settings of the API project, not its own. This is why connection string needs to be in the API project as well. Looks inside the APIs bin folder and you'll see what I mean.
I have created a new application, using the SPA templare of .netcore, to this solution i want to add another project to handle the database connection(DAL).
When i am adding ASP.net core Web Application to this solution, i then want to add to id an ADO.net entityframework template, but in the data section, it dont appear:
So I end-up adding a class Library(.net framework)
and to it i can add an ADO.net Entity Data Model
So now in the solution, i have 2 projects, 1 is .net core 2.1 for the API's, models and views(by angular).
The second project is a .net framework 4.6.1, class library project.
My question is, is it suppose to be like that?
is it a good thing to mix different frameworks
Please see this article regarding what each framework is, and what each is specifically designed for.
https://learn.microsoft.com/en-us/dotnet/standard/frameworks
In a nutshell, your requirements drive which framework you choose.
I would recommend sticking with EF Core (just my personal opinion, take it or leave it) The EF Core method of database first is only recommended if you require a 1 time migration from a source database. Microsoft Doc
If you need to CONTINUE working with an entity model past the first migration, it would be in your best interest to use Entity Framework 6, on a .NET Framework library like you have. But that doesn't stop you from using EF Core as your OR/M, because you can indeed have .NET Core reference .NET Framework.
Okay going to try to keep the fluff to a minimum. First we are new to Breeze. We have a project where the "Database First" Entity Framework was created. Using the SPA approach for offline webpage with AngularJS/BreezeJS combination. Angular seems to be working fine and as stated the Entity Framework EDMX file already exists.
Can I connect Breeze.Net to our Entity Framework and if so are there any examples of this specifically the Server side connection part? But the full example would be best. aka Entity Framework to Breeze.Net to BreezeJS
If I cannot connect Breeze to my Entity Framework, can I do a "Database First" Breeze.Net approach and if yes is there an example of how to do this?
Thanks in advance.
Breeze documentation includes many pertinent samples including the most basic Angular Todo sample. Among the samples, "DocCode" has the most sophisticated .NET Web API / EF variations (you can mentally translate from Knockout to Angular for the front-end).
You can download or clone them all from github.
Most (if not all) EF samples rely on a code-first model but you should have no trouble with a DbContext generated "DB First" (or with an old-school ObjectContext).
We are currently looking at converting from WCF Data Services to WebApi with Odata. Our entity model is defined using an entity framework defined as an edmx. Im struggling to get the edmx working with WebApi OData due to relationships and complex properties.
I'm just wondering whether someone has successfully implemented webAPI with odata on a bigger sized edmx (that has relationships as well)? Any advice would be great.
You may try using RESTier -- a .Net framework built upon Web API OData. There are several things you may need to pay attention:
RESTier has an EF provider which is quite similar with WCF data services. So it should work wiht the edmx model with little tweak.
RESTier is not a "competitor" for Web API OData, it's built upon Web API OData and can fallback to Web API OData.
RESTier currently is a preview version, but it has good support for the common features used of OData service.
If you tried out and find it cannot work, you can create an issues on https://github.com/odata/restier/issues with more detailed information, if you successfully make it work, it will be great you share your experience.
I've been using the entity framework in combination with the self tracking entity code generation templates for my latest silverlight to WCF application. It's the first time I've used the entity framework in a real project and my hope was that I would save myself a lot of time and effort by being able to automatically update the whole data access layer of my project when my database schema changed.
Happily I've found that to be the case, updating my database schema by adding a new table, changing column names, adding new columns etc. etc. can be propagated to my business object classes by using the update from database option on the entity framework model.
Where I'm hurting is the CRUD operations within my WCF service in response to actions on my Silverlight client. I use the same self tracking entity framework business objects in my Silverlight app but I find I'm continually having to fight against problems such as foreign key associations not being handled correctly when updating an object or the change tracker getting confused about the state of an object at the Silverlight end and the data access operation within the WCF layer throwing a wobbly.
It's got to a point where I have now spent more time dealing with this quirks than I have on my previous project where I used Linq-to-SQL as the starting point for rolling my own business objects.
Is it just me being hopeless or is the self tracking entities approach something that should be avoided until it's more mature?
What version of self tracking entities are you using?
I'm using the .Net 4.0 version together with visual studio 2010. All CRUD operations work fine, also operation with FK.
I had problems in VS 2008 with FK but that's gone in VS 2010 with .Net 4.0.
If you want, I can provide you some samples.
Greetings
Since STE entity does not support lazy loading you should use Include on the server side include related properties. There is no way to include all related navigation properties. You have to explicitly include the properties. for instance
//server side
customer.Include("Orders.OrderDetails").Include("Address")