I am having a bit of a free time and i am planning to catch up on some new technology. I started of my .NET development career as a ASP.NET developer. Presently I am done with ASP.NET development,for that matter i am done with any front end development. These days i am into Business layer and DAL development with the primary focus on WCF service development and I am going to continue doing so. Given the situation which one would be helpful for me in moving forward? ADO.NET data services or Entity Framework?
Those are two totally separate items:
ADO.NET Entity Framework is a data-access and data-modelling technology to handle database storage, modelling objects etc. on top of that
ADO.NET Data Services is a REST-ful way of exposing such data models to a wide audience, by means of browsers and URLs
So basically, first you need to know a bit about Entity Framework, and then you should learn how to make that available to the world at large.
Marc
ADO.NET Entity framework and ADO.NET Data Services are different
Related
I've read a lot about OData with EF Core / ASP.NET Core.
It seems to me that everybody has an opinion on this and It's gotten a bit confusing, so at the risk of sounding dumb, I have a few questions:
Please note:
! I'm NOT talking about the classic ASP.NET 4.6 or 4.7 with EF6 !
! I'm talking about ASP.NET Core with EF Core !
Considering building API - Is there stuff that EF Core alone couldn't handle as well as EF Core with OData?
Considering building API - Is it not better to build clean RESTful APIs instead of OData style APIs?
Isn't implementing OData stuff sacrificing best practices for convenience?
What about long term? Aren't ASP.NET Core + EF Core being built with speed and efficiency in mind and thus won't they be faster and more efficient on their own?
I will go with Shawn Wildermuth's advice that I found on Pluralsight:
OData means that queries are on the client so that versioning OData
services becomes risky and it feels like MS is moving away from it so
I don't have confidence in the long-term viability of it either.
OData on ASP.NET Core/EF Core works very well. Versioning can be accomplished with microsofts versioning api.
I don't necessarily see MS abandoning this technology. There main api (ms graph) is odata 4 compatible.
Using Odata on top of EF Core is really enjoyable for many use cases. Especially the querying part I like a lot.
For implementing writes/commands I usually fall back to webapi/Mediatr.
Here https://www.jannikbuschke.de/blog/cqrs-with-mediatr-and-odata/ and here https://www.jannikbuschke.de/blog/odata-getting-started/ I wrote some thoughts/guides on this topic.
One downside is tooling and community. There is not a whole lot out there.
I want to develop ASP.NET MVC site but I am confused about the use of EF. While developing my database structure/tables will be changed frequently and also after going to the production if anything happened?
If EF not for ASP.NET MVC3 then I would use ....... ?
nHibernate
RavenDb
Don't bother with anything else, in my opinion.
nHibernate is a very mature and open source ORM that can use SQL Server to get data into/out of your ASP.NET MVC (and version) project(s). It is the most direct competitor to EF it terms of popular options in the ORM space.
If you like new and cutting edge technology, then give RavenDB a go. It is its own database and doesn't require an ORM. It just saves the class library objects straight to its own DB. Therefore, you don't have database schema migration issues, etc.
I would go for RavenDb IMO. I'm leaving EF because I'm just so sick of SQL Server and all the hoops and barriers to getting my domain models to work nicely with a traditional RDBMS. (And this is after working with SQL Server since '95) ...
I have been using ADO.net since 2002/2003 and most of the application I have developed so far use ADO.net (I do use business objects in my application but underlying data access is through ADO.net)
Question: What is/will be next paradigm of data access technology assuming you are using .net framework and SQL Server?
I am hearing LINQ and Entity Framework but not sure about LINQ or at least its future?
Any advice along with a recommended book will be greatly appreciated.
Object relational mapping is perhaps the next paradigm for data access technology after ADO.NET, although you could say that its already pretty well established. Although Entity Framework is still fairly new NHibernate has been around for several years, and its Java predecessor since 2001.
If you are looking for a good book about NHibernate and object relational mapping in general then NHibernate in Action is good. Its very readable and the first chapter, which is available as a free sample, covers the rationale behind ORM as well as comparisons between NHibernate and other technologies like LINQ.
LINQ is here to stay, what I think you are referring to is LINQ to SQL which while not being very actively developed by Microsoft, is still alive however Microsoft are making it fairly clear that EF is the future.
I'm having a look at Entity Framework and everything I'm reading takes a data centric approach to explaining EF. By that I mean that the fundamental relationships of the system are first defined in the database and objects are generated that reflect those relationships.
Examples
Quickstart (Entity Framework)
Using Entity Framework entities as business objects?
The EF documentation implies that it's not necessary to start from the database layer, e.g.
Developers can work with a consistent
application object model that can be
mapped to various storage schemas
When designing a new system (simplified version), I tend to first create a class model, then generate business objects from the model, code business layer stuff that can't be generated, and then worry about persistence (or rather work with a DBA and let him worry about the most efficient persistence strategy). That object centric approach is well supported by ORM technologies such as (n)Hibernate.
Is there a reasonable path to an object centric approach with EF? Will I be swimming upstream going that route? Any good starting points?
Model First approach seems to be what you need.
We suggest to take a look at the ADO.NET Team Blog article also.
A while after asking this, I discovered that EF 4 supports POCO (Plain Old CLR Objects), allowing an object-centric design with (relative) ignorance of persistence.
This article was the best one I came across discussing that approach, while this article explains how to use code generation templates to ease the work.
I’m working on a high volume transactional enterprise application(asp.net, windows app, oracle app as client) which has been designed using n-tire application and SOA architecture .The application was developed in the .NET platform utilizing C#,VB.NET, Framework 3.5 (I’m planning to upgrade to the , Framework 4.0), EF( EF in the data layer level) and WCF(WCF services in the service layer level)
Since this is the first project using EF, and having read about using EF in n-tier and SOA applications, and the features available in the EF Feature, I have the following points:
Which design pattern should I use in EF( Simple Entities, Change Set, Self-Tracking Entities and DTOs) in the data layer level
In addition Which design pattern should I use in the other tier and layer to get the best practices of EF
Thanks
"In addition Which design pattern should I use in the other tier and layer to get the best practices of EF "
I would use the saperation of concerns using IoC at the root of my design patterns. for Data Layer Abstraction purpose I would definately go for Repository patterns. There are some interesting work which you see on the web for e.g. UnitOfWork for transactions etc.
Not sure about your knowledge in Repository pattern but here's a good start.
There is also a good project on the CodePlex called Project Silk which can give you a good heads up for both the above topics among others.
All the best