We are possibly looking at switching our tables, for views in EF 4.3.1.
We are using db first via the edmx file, so it generates our entities and dbcontext.
Has anyone got any tips for remapping our entities from tables to views?
Is this prone to disaster? We've had trouble with updating the edmx file in the past via the designer where the underlying changes weren't reflected deep somewhere within the code and we ended up with missing columns.
Or will views act very similar to tables in the EF world?
Designer handles views in completely different way - first of all all views used by EF through designer are read only unless you map stored procedures or custom SQL commands to insert, update and delete operation for each entity you want to modify.
Normally if you have updatable view you can simply modify SSDL part of EDMX and cheat it to pretend that the view is actually a table but this has two consequences:
You must modify EDMX directly as XML
You must not use Update from database any more because it always deletes whole SSDL part and creates a new one without your changes = you must maintain your EDMX manually or buy some extension for VS which will allow you updating only selected tables.
Related
I am using Entity Framework 4.1 and SQL Express. I have been trying to create models inside the emdx file and from that create the tables inside the a .mdf file. However, I am unable to get that work.
However, I am able to get the "Update Model from Database" to work, so there don't seem to be a problem with the connection string.
What am I doing wrong?
I tend to copy the generated SQL script and execute it myself using SQL (Enterprise manager 2008 in my case), gives you better feedback and more control.
Haven't really bothered setting it up so that it executes automatically, because EF sometimes makes mistakes in its scripting (e.g. trying to delete every FK twice. Once in the beginning, and then again before the containing table will be deleted).
Also, if you made a lot of changes or dropped some tables, sometimes the script isn't 100% compatible with deleting the existing database. I then just drop all FK's and tables (not just what the script tells me to) and then execute the script.
But that's just how I like to do it.
I have a database that I created for a site using Entity Framework 4.1 code first. I need to add a simple property to one of my entity classes, and add a corresponding (possibly nullable) column to the database without losing any of the data in the database.
I think I can take down the site, alter the database to add the column, and redeploy website with an updated entity class, but I'm not sure that's the best way to do this schema upgrade.
Is there a standard (or just better) way of doing a schema upgrade on a DB that was created using code first?
Entity Framework Code First has a new feature in preview called Code First Migrations, which does simple schema upgrades.
You can check it out here http://blogs.msdn.com/b/adonet/archive/2011/07/27/code-first-migrations-walkthrough-of-august-2011-ctp.aspx
When I modify the structure of the table in Sql Server ,won't it be automatically reflected in the "Dbml" Layout designer ?Each and every time i have to delete the tables in "dbml' layout designer and drag the table from sql server.
It would be nice if you had the option to "refresh" keeping any local customizations that you've made, but the designer doesn't seem to work that way. You can, however, simply make the same updates (by hand) in the designer that you've made to the table by adding/deleting columns from the generated class in the designer.
If I were you I'd start using SqlMetal. SqlMetal is a command line application used for generating LINQ DataContexts. It can generate dbml's or just a set of classes for you to use in your project (it's pretty customizable). So create a batch file that calls SqlMetal and run it every time you make database changes and your project will always be up to date with the database.
If you don't want to run the batch file every time you update the database you could just run it every time you build your application with a pre-build step.
There are a number of ways to keep the L2S model in sync with the underlying database:
1) Delete the table(s)/classes involved from the designer surface and drag them back from the 'server explorer' thing.
...or...
2) Update the classes involved manually in the L2S designer.
...or...
3) Use third party tools with update capability (one such tool is my add-in: http://www.huagati.com/dbmltools/ , also mentioned in the Dec 2009 issue of MSDN magazine http://msdn.microsoft.com/en-us/magazine/ee819138.aspx)
...or...
4) Regenerate the entire DBML file using either the designer or sqlmetal.exe.
I have a Client/Server application, where the Client and Server have some common tables (which are kept in synchronisation as part of the application).
We currently store these tables (i.e. FileDetails) in a Shared.dbml file. Until now, any stored proc that returns a result of set of FileDetails, has been placed in the Shared.dbml (even it is a Server-only) SP.
I released that the LINQ to SQL supports a Base Class property on the DBML, and I thought that perhaps I could have a Server.dbml, that extends my Shared.dbml. In theory this would give me a ServerDataContext with all the shared tables and SPs, as well as the server-specific elements. Normally in the SQL designer I would drag and drop the SP, over the FileDetails table to show this is what was returned, however as the class is in a different DBML this is not possible, and in the XML I don't think the ElementType IdRef="1" approach will work (as the ref needs to point to another file)
I found I can get around that problem by editing the XMLs return type manually:
<Function Name="dbo.SELECT_FTS_FILES" Method="SELECT_FTS_FILES">
<Return Type="ISingleResult<DataTypes.FileDetails>" />
</Function>
My question is, does anyone have any experience with this kind of approach, and could point me to further resources? Are there any obvious drawbacks to it (other than than manual XML updates)
All feedback welcome
You could inherit from your datacontext. However in your new datacontext you wouldn't be able to use the linq designer you would have to code things out manually.
Is there any reason you don't want two datacontext?
Inheritance and LinqToSql don't play nice together in general. If you have a deep need for it you should look into another ORM like NHibernate.
First a bit about the environment:
We use a program called Clearview to manage service relationships with our customers, including call center and field service work. In order to better support clients and our field technicians we also developed a web site to provide access to the service records in Clearview and reporting. Over time our need to customize the behavior and add new features led to more and more things being tied to this website and it's database.
At this point we're dealing with things like a Company being defined partly in the Clearview database and partly in the website database. For good measure we're also starting to tie the scripting for our phone system into the same website, which will require talking to the phone system's own database as well.
All of this is set up and working... BUT we don't have a good data layer to work with it all. We moved to Linq to SQL and now have two DBMLs that we can use, along with some custom classes I wrote before I'd ever heard of Linq, along with some of the old style ADO datasets. So yeah, basically things are a mess.
What I want is a data layer that provides a single front end for our applications, and on the back end manages everything into the correct database.
I had heard something about Entity Framework allowing classes to be built from multiple sources, but it turns out there can only be one database. So the question is, how could I proceed with this?
I'm currently thinking of getting the Linq To SQL classes all set for each database, then manually writing Linq compatible front ends that tie those together. Seems like a lot of work, and given Linq's limitations (such as not being able to refresh) I'm not sure it's a good idea.
Could I do something with Entity Framework that would turn out better? Should I look into another tool? Am I crazy?
The Entity Framework does give a certain measure of database independence, insofar as you can build an entity model from one database, and then connect it to a different database by using a different entity connect string. However, as you say, it's still just one database, and, moreover, it's limited to databases which support the Entity Framework. Many do, but not all of them. You could use multiple entity models within a single application in order to combine multiple databases using the Entity Framework. There is some information on this on the ADO.NET team blog. However, the Entity Framework support for doing this is, at best, in an early stage.
My approach to this problem is to abstract my use of the Entity Framework behind the Repository pattern. The most immediate benefit of this, for me, is to make unit testing very simple; instead of trying to mock my Entity model, I simply substitute a mock repository which returns IQueryables. But the same pattern is also really good for combining multiple data sources, or data sources for which there is no Entity Framework provider, such as a non-data-services-aware Web service.
So I'm not going to say, "Don't use the Entity Framework." I like it, and use it, myself. In view of recent news from Microsoft, I believe it is a better choice than LINQ to SQL. But it will not, by itself, solve the problem you describe. Use the Repository pattern.
if you want to use tools like Linq2SQl or EF and don't want to have to manage multiple DBMLS (or whaetever its called in EF or other tools), you could create views in your website database, that reference back to the ClearView or Phone system's DB.
This allows you to decouple your web site from their database structure. I believe Linq2Sql and EF can use a view as the source for an Entity. If they can't look at nHibernate.
This will also let you have composite entities that are pulled from the various data sources. There are some limitations updating views in SQL Server; however, you can define your own Instead of trigger(s) on the view which can then do the actual insert update delete statements.
L2S works with views, perfectly, in my project. You only need to make a small trick:
1. Add a secondary DB table to the current DB as a view.
2. In Designer, add a primary key attribute to a id field on the view.
3. Only now, add an association to whatever other table you want in the original DB.
Now, you might see the view available for the navigation.