We have a very large stablished database (PostgreSQL for the matter) that suffers from standardization and I'd like to use Entity Framework in our future-to-be ASP.NET MVC application.
Is there a way to manually write Entities mappings?
I really don't want to autogenerate Entities based on Database First approach. And I don't have the option, for now, to migrate/update our schema.
Thank you.
Edit: after some more thinking we decided using NHibernate with Fluent NHibernate for the mappings.
We decided to go with NHibernate and Fluent NHibernate for mappings.
Related
I am curious to know that if Entity framework can create tables in other databases besides MS-SQL ??
Moreover, is there any provision to create XML schema through EF ?
Under the hood Entity Framework uses providers that are specific for different databases. So it depends on a provider whether EF can create tables or not. However, I haven't heard about providers that do not have this possibility. The easiest way to be sure is to write a simple program with a few lines of code.
As to XML schema. Are you asking about using XML files instead of database as the storage for your data? If so, again it depends on the provider. If you want you can theoretically create one that will use XML files. However, I haven't tried to do so and I don't think that it is a good idea. There are technologies that fit here better (see this question).
Is there a way to add/delete columns in the database using database-first approach in Entity Framework? I know we can do this by doing code-first approach.
I need to migrate data from many xmls to a sql server db and and it has to be done in a transactions.
I thought about EF and dbContext as it's a UOW in it's own right.
My question is
Can you do Database First at run time?
What I want to do is Read all tables from db store in class/dataset and map the db.column to equivalent in xml file and commit.
This has to work in such a way that if a table is added or column added it will work without any code changes as it is driven by db.
The problem I face is that with Db generated from model if a new column is required somebody later on "unfamiliar with EF" as to add the column "manual job".
I can do what I want with raw ado.net by reading db schema and mapping to a dataset but wondering if I could do it using EF.
Hope all clear
any suggestions
Yes you can.
You can use Entity Framework Power Tools which allows you to create Code-First file from Database of yours as you start like Code-First.
Or, you can use Database-first approach also. It's not that hard.
If you try to use database-first approach, please read my trial-and-error experience: post1, post2
we know that we can generate EDMX model from sql server because EF support sql server. if my database is Oracle,MS-access or MySql then it supports or not. does it support ODBC.
EF is database independent but it requires EF ADO.NET provider to be supplied for the database. You can check the list of databases offering such provider. MS-Access is not among them.
The independence is little bit more theoretical because if you are using EDMX it has always its SSDL part bounded to single provider. If you want to support more databases you must have separate SSDL or whole EDMX for each provider. This is not the problem with EFv4.1 and code-first approach.
Linq to entities seems much easier and safer than entity SQL.
Can you give an example where using entity SQL makes more sense than Linq to entities?
Personally I think the best use for EntitySQL is when you don't have any CLR classes for your entities:
I.e. using eSQL you can query against the conceptual model (with all the mapping flexibility the Entity Framework offers) without actually needing classes for each of your entities.
Alex
Entity SQL was the original language design for use with EF and bears many similarities with T-SQL. It can be a very useful stepping stone for migrating your DBAs to a domain-modelling framework. They can then move on to 'proper' LINQ to SQL.
The main difference is that the first call of Entity SQL query is much faster than the call of the LINQ to Entities query (if itis not using CompiledQuery).
One more EFv1-specific feature is that internal database functions (defined in the provider manifest) could have been called only in Entity SQL queries.
Devart Team
http://www.devart.com/dotconnect
ADO.NET data providers for Oracle, MySQL, PostgreSQL, SQLite with
Entity Framework and LINQ to SQL support
You can specify a (database) collation in ESQL, which you can't do in L2E (or LINQ-to-anything, actually). You can also specify the exact type with ISTYPE(ONLY ...), which you can't do in L2E.