I've been using this nifty LINQ to SQL tool for a data access layer in an asp.net project. I keep making changes to the underlying tables and in order for the data classes to recognize the change I have to delete and readd the table which has changed. Is there some shortcut to regenerating the data layer?
I've run into this same problem and using sqlmetal is definitely a good way to solve it. One approach is to create a batch file that executes your sqlmetal command and that way you can just run the batch anytime you need update your Linq to SQL classes, but what is even slicker solution is to use Visual Studio's Tools->External Tools function to create a command in Visual Studio that runs sqlmetal with your parameters. This works great and you can even drop the created command onto your toolbar for single-click rebuilding.
You could use sqlmetal which is the command line class generator for linq to sql classes.
LINQ to SQL version 1 does not support detecting database schema changes. The only way to have the generated classes modified is to regenerate them with either the designer or SQLMetal.
Keep in mind that there are not many differences between SQLMetal and the designer, the designer is a more 'pretty' UI for SQLMetal, and hides many of the command line switches.
I use the designer as I'm too lazy to constantly load up the command prompt.
In addition, make sure that you don't write any of your own code into the generated classes, otherwise you'll loose it on a regen. All generated classes are partial which means you can easily add your own extenders in a separate file.
For situations/models where SQLMetal don't quite cut it, e.g. due to different naming conventions in the database and your model, or some other customizations in your L2S model I have an add-in for Visual Studio that adds commands to synchronize your L2S designer with the underlying database [schema]. (plus a bunch of other L2S and EF related features)
You can read more about it, download it and get a 30-day trial license from http://www.huagati.com/dbmltools/
In the past where I've worked, we created a wrapper class to the DataContext that sqlmetal generated. Then we created a thin data layer that kept private the DataContext and all the classes generated by sqlmetal.
If any operations in the software needed information from the database, they had to go through this wrapper layer to get it. In other words, no LINQ to SQL could appear outside of this data layer.
That way, whenever we had to regenerate classes via sqlmetal, only portions of the data layer could break. Much easier to fix one layer where all the data access code is than to change sprinkles of LINQ to SQL throughout your logic or application domain.
Related
I've just made my database using Entity Framework Code First and everything is working great. However I want to see the schema of the entities; almost like generating an EDMX from the code first, but it doesn't have to do anything.
How do I do this I hear there is a nuget package for it, but i'm not finding it.
Thanks for the help!
The tool is called Entity Framework PowerTools CTP 1 and it is not NuGet package. It is standalone installer available on VS Code Gallery.
If you're using the Code First approach, you don't have .edmx schema/mapping files. The relationships between entities can be found within the POCO models themselves.
If you definitely want to use .edmx files, however, you can use the Database First approach. In that case, you would create your database manually and let the entity data model be automatically generated for you.
I have the situation where I'm working in a new database, built using a Visual Studio 2010 database project, which has a number of synonyms defined which point to our legacy database.
Our plan is to create views over these synonyms; the tables being referenced are horrible, so the views will mangle the data into a better format; after that we will use Entity Framework to provide an ORM for these views (the idea being that we can then swap the views for real tables as we migrate data).
Problem: I can script the synonyms in the database project with no problems. However, when I try to create a view which references these synonyms, I am confronted with an error similar to:
Error 1 SQL03006: View: [dbo].[Person] has an unresolved reference to object [dbo].[ma_contact].
...where [dbo].[Person] is the new view and [dbo].[ma_contact] is the synonym for the legacy table.
Workaround: Place all view creation scripts in Script.PostDeployment.sql, doing the if-exists-then-drop-then-create logic manually.
This is less than ideal, although it's livable-with for now. Anyone have any ideas as to how to do these views "properly"?
Have you tried adding a database reference to your original database? You'd have to extract its format into either a dacpac (for SSDT SQL Projects) or a DBSchema file (for DB Projects). Once you've done that, store it in some place the project can find it. We used a "Schemas" folder at the root of our DB Projects so all projects could reference it. In your project, right click the "References" folder and add a Database Reference. Search for your DBSchema/Dacpac file and use that, along with the name of the database. That should let your synonym resolve properly so you can reference it in your views.
I'm building an asp application from the ground up using Linq-to-SQL as my ORM. I have a dbml file with a datacontext that includes all the tables of the database (15 for now). If I make changes to the database, by adding a table, adding fields or by changing the data type of a field for instance, how are these kinds of change handled when they occur?
Do I simply drag and drop the new table on the ORM mapper and voila?
Thanks.
Have a look at How to update Linq to SQL dbml file? [best practice] there you will find your answer.
I prefer to use SqlMetal (via a bat file) to fully regenerate the DB schema.
However, you'll find that SqlMetal generates for the entire database. To remove certain tables or relationships; and/or to rename certain tables or generated properties you could look at my blog on filtering items generated by SqlMetal using Powershell.
However, you could of course do it all via the visual studio designer, but that's manual and annoying to repeat for a small change. Or you could manually deal with DBML but that is nasty.
The Visual Studio IDE transfer the changes you do to your dbml file to your ORM classes automatically.
I'm trying to figure out how to make the generated LINQ to SQL classes be marked private instead of public, so that it is not visible outside the assembly. There doesn't seem to be a way to do this in the Visual Studio O/R designer or the SqlMetal tool, unless I'm missing something. Is there a way to do this?
I'm asking because I'm using LINQ to SQL internally as a data access layer in a business logic assembly. I am exposing to clients a separate set of custom entity classes, and I don't want the LINQ to SQL classes to be exposed at all.
It is possible, in the Visual Studio Designer select the class and in properties you can change Access to Internal.
alt text http://img410.imageshack.us/img410/970/l2svs2008access.png
The same principles apply for the DataContext itself (just click in the "white area" of the designer) and change under Properties.
I love Linq but it can rapidly clutter up the namespace with automatically generated types. Usually these automatically generated types are often irritatingly close to other objects leading to many hours of fun and laughter.
In the designer I notice that I can specify the table names, however I can not for the life of me see how to set the row names.
For Example
TableName : User_Table
RowName : User_Row as opposed to "User_Tables"
I swear I've done this before but I can't seem to remember how.
You can do this by manually editing the dbml file in an xml editor. All names are stored separately in the dbml file, but not all are accessible from the designer.
Alternatively, there are third party tools that make handling names etc easier; one such tool is my VS add-in for L2S and EF. It adds naming rule support, mass-renaming, model <-> db schema sync etc to the existing L2S designer. You can download it from http://www.huagati.com/dbmltools/