Breeze.Net Connecting to Entity Framework - entity-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).

Related

Entity framework support in .net core 2.1

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.

Breeze WebAPI Entity Framework Self Tracking entity not working

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.

How different are EF 4.0 and EF 4.1?

I guess that EF4.1 is recent to EF4.0, but I didn't find any book on EF4.1, but 2 books on EF4.0.
can I still buy the book on EF4.0 expecting that I will get most of the concept??
Thanks for helping.
According to The ADO.NET Team blog, there are two main features:
The DbContext API is a simplified abstraction over ObjectContext and a number of other types that were included in previous releases of the ADO.NET Entity Framework. The DbContext API surface is optimized for common tasks and coding patterns. DbContext can be used with Database First, Model First and Code First development.
Code First is a new development pattern for the ADO.NET Entity Framework and provides an alternative to the existing Database First and Model First patterns. Code First is focused around defining your model using C#/VB.NET classes, these classes can then be mapped to an existing database or be used to generate a database schema. Additional configuration can be supplied using Data Annotations or via a fluent API.
EF 4.0 books are good unless you are using one of those 2 features, because you won't find them in there.
But you have plenty of resources online about those new features (especially Code First).
You even have official tutorials:
Using DbContext
Code First walkthrough

EF 4.1 model first code generation tool or template

Is there a template or tool to generate code from the database directly? I want to use model first scenario but do not want .edmx file for mappings. There is a database with many tables and I do not want to write all the classes (I am lazy) for that. So, is there a template to generate the code and set the annotations/use fluent api for defining the relationships, etc automatically from the existing database?
This would be helpful in the following scenario as well. Say, I was using .edmx with POCOs and now I do not want the mappings in the .edmx file. I want the mappings in the code. It would be great to have a tool or a template to generate the mappings in the code from the existing database.
I am starting on learning EF 4.1. I think "Code first becomes model first in version 2 i.e. after the database is created/released (in version 1) and needs some changes". Is that really true? I'd love to hear some comments. Thanks.
Check out the 'Reverse Engineer Code First' feature of the EF Power Tools CTP1 that was just released.
For generating classes, you can use POCO t4 template generation. Have a look at this detailed link which will help you getting started. That way you will get all the classes generated.
For mapping, you can use Code-Only style for Entity Framework but generating classes and context using POCO template will have far more advantage over creating the mapping yourself. Imagine adding new tables or modifying the tables, it will involve more work. But I will certainly love to know if there is any mapping tool for that.
It is possible that you are using EF-provider Devart dotConnect for Oracle when working with Oracle database. In this case the following information will help you to choose the tool.
The first version of Entity Framework Power Tools also contained the capability of generating a Code-First model with fluent mapping from an existing database. Although useful, this functionality is limited as regards its flexibility: the developer can only set the connection string; following that, classes are generated from all database objects available to the user. That is not extremely convenient, since in Oracle, for example, numerous schemas containing hundreds and sometimes thousands of tables are available to the user.
Rather than resort to this limited functionality, the users of Devart ADO.NET providers can avail themselves of impressively robust design-time development capabilities of Entity Developer, an EF-designer delivered with Devart providers. Also possible is the choice between the Database-First approach, as provided in EF Power Tools, and the Model-First approach, within which Code-First classes are created in the EDM-designer.
When compared to EF Power Tools, the Database-First approach to the development of EF Code-First models also allows selecting objects that must be available in the model, setting naming rules for the generation of class names and properties and so on. Besides, the resulting model can be modified and improved in the designer.
To better meet developers' needs, Code-First code generation in Entity Developer both for C# and VB is based on the T4-template that is easily accessible and can be modified in feature-rich T4 Editor contained in Entity Developer.
For more information on Code-First development in Entity Developer, see "Entity Developer – EF Code First DbContext Template"
http://www.devart.com/blogs/dotconnect/index.php/entity-developer-ef-code-first-dbcontext-template.html

ADO.NET DbContext Generator vs. ADO.NET Poco Entity Generator (ObjectContext)

I am about to start implementing the data access infrastructure of a project that was architected with an approach to DDD (it's my first attempt on DDD, so be gentle ;-) ).
I will be using Entity Framework. Until now, I was looking into the method teached by Julie Lerman on her great book, Programming Entity Framework, where ADO.NET POCO Entity Generator is used, with some changes to the T4 templates and some more custom code.
Today I started reading articles on EF4.1 and the ADO.NET DbContext Generator, using Database First approach, and I'm trying to decide with which one should I go.
DbContext and EF4.1's approach on DDD seems to be a nice, cleaner way than POCO Entities, but I'm afraid that it could lead to some issues in the near future, since EF4.1 is still in RC.
From ADO.NET team blog, I know that EF4.1 does not include:
Enum support
Spatial data type support
Stored Procedure support in Code First
Migration support in Code First
Customizable conventions in Code First
From my understanding, since I will be using Database First there is a smaller number of features that were not included.
In conclusion, my question is:
Can I replace POCO Entities Generator with EF4.1 DbContext Generator?
From a point of view of clean creation of POCO entities, there is no difference between the two generators. Both generators produce the same entities, however, ADO.NET POCO Entity Generator is based on ObjectContext's API, whereas ADO.NET DbContext Generator is based on DbContext's API.
DbContext's API has a few very nice new features (Local, Query on navigation property, etc.) and API is somehow simplified but at the same time it looks like some features used in ObjectContext API are missing in DbContext API (or at least it has not been explored enough yet).
EF 4.1 RC is go-live release. It means that you can build a real application with it because API will not change in RTW (only bugs will be fixed). Also RTW should be in the next month so I think you will not be ready with your application before the final version is shipped.
ObjectContext API or DbContext API? ObjectContext API is much better covered by documentation and blog posts. You can find plenty of examples about it. Also its limitations are already well known. DbContext API is new release. A very promising release, mostly because of the code-first approach. There is still a very limited number of blog posts, no book and the API is not proven enough. So it depends if you are ready to fight with new API? If not, then ObjectContext API is still a good choice because you don't need the code-first approach.