I'm currently investigating ASP.NET MVC 2 and LINQ to SQL. It all looks pretty cool. But I have a few application and development lifecycle issues.
Currently, I design the DB in SqlServer Management Studio.
Then I update my DBML files by deleting and re-importing modified tables.
Issues:
I can't find how to simply update the whole DBML schema.
My DBML then loses some of the changes I made such as renaming relation members or mapping of some int to an enum.
If I want a SQL script to deploy my DB (or to keep the schema under source control), I need to go use the 'Genererate Script' SSMS wizard which would be cool if a) it could remember my settings and b) it could be automated.
Should I work the other way around (start from my DBML and generate the DB)? Should I go for some other framework (NHibernate? Can I use some Linq flavor with it?)
Also, I read that LINQ2SQL is already obsolete in favor of Linq to Entities. Does it mean that the ultimate tool supposed to make my life so much better will again make me lose time in the long term?
Thanks for shedding some light.
If you are starting your DB Schema from scratch you could consider "Code-First Development with Entity Framework 4" as outlined by Scottgu.
I have been using this on a new project and am finding it extremely beneficial - especially for testing.
I started with simple POCO classes representing my data, then as the project progressed I would allow EF4 to generate the schema to a "real" DB using my "in-memory" example data ... now I am using a mixture of both in memory POCO (for development and TDD) and auto-generated DB Schema (auto-loaded with more "realistic" data) for demonstrations etc ... so far I am very happy.
There is a lot of opinion over LINQ2SQL and whether it's 'obsolete' or 'discontinued'. But it is still in the .NET framework and a good tool, so if it suit your needs then you should use it. Frankly the Entity Framework is still not perfect and if you don't need the extra flexibility that it affords then it is not worth the pain. If I had a small to midsize project then I would definitely use LINQ2SQL again (and over EF).
As for your question, yes you'll lose any names or different type mappings when you remove and re-add a table. The options that I'm aware of are
Only remove / re-add the table that has changed (not all tables)
Try altering the DBML tables in place, rather than remove / re-add. You can add and remove columns, change column names and data types, add relationships all on the DBML.
I like JcMalta's suggestion of creating objects as classes before rendering into the database, but if you find SQL Studio to be quick to develop with then it might simply be quickest to create tables there are drop them into your DBML. It's a touch annoying to have to change something in a database and the push the changes into your code but the code-gen tools are quite good and take away most of the pain.
You can try CodeSmith/PLINQO to auto-sync DB/code:
http://plinqo.com/
As a follow-up, just wanted to say that I eventually found and fell in love with Huagati DBML/EDMX Tools.
To be totally honest, I must say that the price has significantly increased since I purchased it. I believe it is still worth the money anyway.
And for people who are looking for the same kind of tool for MySQL (or other), DevArt is your friend.
Related
I've always been intrigued by Visual Studio Database Projects, and while they seem to be quite capable, I've never used them to any great degree outside of simplistic proof-of-concept work. I want to try this for a new project, and I'm also interested in using an EF layer on top of it, but in past test projects this has involved some decent effort.
I'm curious: has Visual Studio matured its product integration to support a single workflow that builds the database project, builds the EF layer on top of it, and finally builds the code, without intermediate steps involved?
We are a small team and we don't have dedicated SQL developers, and our primary goal is to bring the database into Visual Studio and to get it nicely under source control (TFS), and to achieve strong integration between from end to end. We're interested in growing into EF, and will probably start simple by treating it like a simple ORM tool to begin with if possible.
Has anyone actually done this that can provide insight into the process?
We have used VS2014, tool seem much the same and early version
Don't think has been much changes over the years
We have EDMX model and a DB project in the solution
Does mean that you need to keep the db project up to date.
But this is easy to do, you just publish you EDMX to local box/target
Then can import the changes with a schema compare of local to the project.
So they you can still have Model driven DB design
And use the DB project to deploy changes to the Dev/Stage/Live boxes
And can publish with automated deployments also.
The db project has a post build scripts option
Where you can use it to do seed data
And also a pre-build where you can do db manipulation if need to change structure and types of fields types when the data is on a live db.
Schema compare tool are rather good in Visual Studio
Can compare a DB to DB, DB to Project, or Schema file to either also
I want to track all changes made in my ERD in oracle 10g designer.
Please suggest how to achieve it.
use case: An ERD was approved in design phase. Few changes were made by development team and now in Implementation phase I need to track what all changes were made from say 3-Jan-12 to 3-Mar-2012
To add here:
1. In my project versioning of ER is not being used so ER Version diff is not an option for me.
2. In Reports, there are options for getting all entities, attributes which are created/modified in a period. But it seems it is not giving me correct results.
Oracle Designer 10g does support the SCM repository, which is the only real way of tracking changes to our models. However, documentation is thin on the ground, probably as a matter of policy since Oracle pulled the plug on Designer as a tool with a future.
Oracle SCM is very powerful but not at all intuitive. This should be obvious as we're working with rows of data rather than files like in most other source control scenarios. Anyway, the upshot is, doing what you want to do won't be easy and you'll need resilience and persistence. You might be able to find some old lags in the ODTUG Designer forum who still have some interest in the tool.
The other thing is, if you haven't already enabled the SCM you won't be able to retrieve the changes in the ERD over the last three months except through data mining.
I usually create a solution folder in Visual Studio and put my DB scripts in them. I always use at least this set of scripts:
Drop model
Create model script
User functions
Stored procedures
Static data (lookup tables)
Test data (not deployed)
Then I simply combine them and run against an SQL Server so I'm able to recreate the whole DB in a single step (by combining these scripts into a single one and executing it).
Anyway. I've never used projects in either:
Visual Studio or
SQL Management Studio
I've tried creating SQL Server 2008 Database Project in Visual Studio 2010, but I'm somehow overwhelmed by all the possible server settings (which I prefer to stay default as set on the server anyway). So I'm a bit confused: Should I use this project template or should I just do the same thing I always did?
What do you use and why? What are advantages I may benefit from by using either?
If I were you I would continue to do it the way you are doing it. In fact I do! The advantages of having the actual .sql files right there in a folder for you to use/edit/look at in my opinion are far better than the advantages you get by using a DB project. DB Project would be used if you were doing something like Storage Reports, were you have to communicate with like 8 databases and compare then to 8 different databases and save result sets etc... Now don't get my wrong there are advantages of Database Projects, I just don't think they are actually doing much help when you have such a simple setup that works already.
Advantages of the SQL Server 2008 Database Project in VS10:
Not having to switch back and forth
from your current client you use to
communicate with your SQL server.
Decent Data and Schema compare tools.
Gives you a one-click way to reverse
engineer a database into source
control, and keep it up to date.
You can compare projects to physical
databases and vice-versa. (This makes it pretty easy to keep your database up to date, no matter where you make change it: file system database project, or in the physical database itself)
If the current tool your using is not specifically tailored to SQL Server, this one is.
Extremely helpful if you need to do
unit tests directly on the database
without using abstractions.
If you're looking for something a little less complicated, you might want to try SQL Source Control. This won't even require you to maintain scripts, as it doesn't this for you behind the scenes. It will, however, only work as a solution for you if you use either TFS or SVN. And it costs $295...
It has a 28-day trial period, so if you're happy to try it out, I'd be interested in your feedback.
I'm generating domain model using LINQ to SQL via the VS2008 built-in editor. That works really well, too; when I adjust my database schema I simply delete everything from the editor and then pull it back in from the server explorer by selecting all tables and dragging them into the designer surface. That works great too.
Now the problem: I have properties that I manually set to autogenerated, readonly etc. using the property inspector on the right. Everything I re-create the entire schema I have to do this manually all over again.
Is there a way to persist these settings externally and/or automate them to bring it back to the state from before?
You can use something like the Huagati DBML Tools. This will allow you to update the DBML file from the VS designer.
I've also used the following process before:
Create my schema in SSMS
Create a script that uses the SQL Metal command line tool to generate the DBML file
As the DBML file is XML, you can run transformations on the file. I used this to simply change a few things like setting certain fields to be auto-generated (DateCreated, etc).
Then, either use SQL Metal or T4 to create the model files from the altered DBML file.
This process worked great - however I had complete control over the database schema. This process also allowed me to use L2S with SQL Server Compact Edition.
Hope this helps!
T4 Toolbox has a Linq to Sql Schema generator which allows you to develop your Linq to Sql applications in a model first approach. I have used it a little and it works really well, here is a blog post with details and usage info.
Your solution may appear to work when you have very few database entities / tables, but it does not scale and as you've found, syncing is less than ideal.
Do not use the Visual Studio 2008 LinqToSql O/R Designer
After looking at many alternatives to the problems you are describing with LinqToSql, I decided to abandon LinqToSql altogether as I didn't find any of the workarounds very good. Competing ORMs don't have the silly problems that LinqToSql has and they are much more mature and feature rich.
I could/should probably list some of the alternatives I ran across, but I don't want to spend the time and give you false hope, sorry.
I'm fairly new to LINQ to SQL, so I could be missing something basic here.
I created a LINQ to SQL layer, generated all the dbml files etc., and created a LINQ query which worked fine. I then made a change to the database, and wanted to get that change reflected in the ORM layer. To do this, I deleted my ORM layer and created a new one (may not be the best way?).
Now my code is not able to see the datacontext object in intellisense and won't compile. I imagine this may be something simple, but I'd also like to understand the bigger picture of how to update the LINQ to SQL ORM layer when the database changes.
Yeah, you don't want to delete your whole DBML file. Open it in the designer, and delete the table that changed. Then drag'n'drop it again from the "Server Explorer" (in the view menu). This will load an updated copy of teh database...
Note that if server explorer is already open while you make the change to the SQL schema, you'll need to refresh server explorer so it has the latest versions.
The drawback to this approach is that if you do customizations to the table in the DBML, those need to be redone. This is an infrequent case for me.
I remember having this issue a bunch. The fix is simple, really. Rebuild your solution! The DataContext and other such classes are generated during a build.
Quite a headache - I wish the DBML tool did this for you when you closed it.
You can also use SQLMetal to update your DBML classes. Some people even write a script or batch file to automate the process.