If I were to write an application in IronPython 2.6, how easy would it be to use ADO.NET Entities as the DAL? Can anyone point to an example?
According to this post, the answer is no.
It looks like you can write your entire DAL in, say, C#, and call those methods from IronPython, but there won't be any linq support in IronPython.
Related
Microsoft provides two ways of working with cosmos dbs in C#/.NET.
One can either use Entity Framework(EF) Core, which makes use of the cosmos SDK behind the scenes and allows you to use EF with Cosmos.
This last point could be seen as positive or negative depending on if you want to use EF vs Dapper or whatever, but for my use case, I would prefer to use EF unless given a good reason not to.
Microsoft themselves has not made any statement I can find on which should be used or why. (I Assume this is a .NET Core project)
EF Core works only for SQL API of Cosmos DB as of now. So, If you are using other APIs, you cannot use EF Core.
Also, Take a look at other limitations of EF Core Azure Cosmos DB Provider Limitations at https://learn.microsoft.com/en-us/ef/core/providers/cosmos/limitations
We used Cosmos DB SDK which is quite flexible and the performance is also good.
After an experience with Cosmonaut package, EF Core and SDK I have to say that Ef Core is focused on relational mapping. Witch Document DB you need to focus on Json serialization. Ef Core model configuration feels cumbersome and limiting for document DB interaction - You have to configure things that just works while serializing. Both Cosmonaut and SDK allow focusing on serialization which in most cases just works. Cosmonaut is a convenient facade on top of SDK - but looks dead at the moment so I recommend SDK.
What are some options for persisting data on .NET compact framework 3.5?
So far I know about the following:
DB options:
sqlce
sqlite
Serialization/deserialization options
protobuf.net
json.net
Are there any more you could suggest (even good comercial products)? Which would you suggest and why (pros/cons)? Thanks!
You could look into db4o, they have an open source version to try, and it supports Compact Framework as well as full framework.
They've actually did a great work porting Mono.Cecil and System.Linq.Expressions to .NETCF for their product to work, so you get those as a bonus.
I'm creating an article related to ado.net. I want to verify if this is true or not because some people said that using ado.net in accessing database is obsolete now. And what's the difference between ado.net, entity framework, ORM, O/R, linq? Could someone enlighten me? thank you very much!
Both LINQ to Entities and Entity Framework use ADO.NET internally, so I wouldn't say it's obsolete.
There are certain cases when using ADO.NET is recommended more then L2SQL and EF, especially when performance really matters and you are able to sacrifice the ease of writing code in exchange to full control over what is send to database and when.
Entity Framework & O.R.M. using ADO.NET on back end. These framework are more optimized and efficient than the simple ADO.NET. While LINQ To SQL are more faster than ADO.NET because it doesn't use the functionalities of ADO.NET
I heard that companies that use Java technologies, they used to build their own custom Framework that wraps Hibernate. However, is it really feasible for their .Net peers to do the same thing with NHibernate or Entity Framework?
This is almost always a horrible idea - I think Ayende sums it up best in this article. In general, you should consider NHibernate itself to be the "wrapper" around your data access - attempting to build an abstraction layer on top of it is probably going to be a losing proposition.
Actually, you should check out some of the articles on .NET Junkie's weblog. He wrote several great posts on how to deal with repositories, queries, commands and so on. We've been using these in a very large enterprise system where we switch between an in-memory dictionary, an in-memory SQLite database and a production environment using SQL Server or Oracle. Obviously, we use NHibernate for this.
I use the repository pattern and a separate project/dll to abstract away the data framework nhibernate / entity framework. this is a good starting point http://codebetter.com/petervanooijen/2008/04/04/wrapping-up-nhibernate-in-repositories/
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.