2

I am new here so hello.

I am using ASP.NET 4 and I am using LINQ to SQL for my data controls. As advised I create a DBML (LINQ to SQL Class Item) and then drag on the relevant tables from SQL Server. I then use this DBML in my code with LINQ ie:

        using (ProjectDataContext Data = new ProjectDataContext())
        {
           Order MyOrder = new Order();


        }

and this all works fine. I have now come across SQLMetal. I cannot see the relevance of this tool, am I missing something?

Thanks,

Ed

Mathew Thompson
  • 55,877
  • 15
  • 127
  • 148
EdB
  • 449
  • 6
  • 21

1 Answers1

2

As you've used the wizard to drag the tables across from SQL, that has in turn generated the objects for you, so there is no need for SQLMetal.

SQLMetal is a command line tool that you could have used in order to generate these objects from linq to sql, but it's far easier to just drag and drop them in the wizard. It also has it's other uses. For reference, see here: http://msdn.microsoft.com/en-us/library/bb386987.aspx

Mathew Thompson
  • 55,877
  • 15
  • 127
  • 148
  • Hi, Thanks for this very prompt reply. Are there any performance issues when using the wizard as opposed to SQLMetal? My other suspicion is whether it might be useful in refreshing DBMLs if the DB schema changes since I have been told that it is best practice to rebuild the DBML if the DB Schema does change. – EdB Apr 04 '12 at 13:44
  • @EdB No problem, from what I've seen SQLMetal is supposedly faster, but it's going to be harder to implement as you're going to have to get your hands dirty and do some command line coding. Here's a couple of links (2008 I know, but I couldn't find any more recent): http://www.mssqltips.com/sqlservertip/1825/creating-linq-to-sql-object-models-using-sqlmetal/ and http://blog.csainty.com/2008/02/linq-to-sql-sqlmetalexe.html – Mathew Thompson Apr 04 '12 at 14:13
  • mattytommo, thanks for this. I think the problem with all of this is that the technology is moving so quickly. I believe that MS would prefer us to use LINQ to EF now and not LINQ to SQL. Hence my concerns as to whether any of this SQLMetal stuff is a little obsolete. I have seen something similar for EF, but if at the end of the day one can achieve most of this via VS then perhaps I need not worry. The bigger concern is whether I should move to LINQ to EF !! Cheers... – EdB Apr 04 '12 at 16:31
  • @EdB No problem! Yeah technology does move fast, but remember in this instance the comparison is between EF and Linq to SQL, both are what's called ORM (Object Relational Mapping) tools. Some people prefer to just stick with SQL rather than an ORM, not like SQL is going anywhere soon. At work we use NHibernate, that's another ORM that's like EF, but not from Microsoft. I wouldn't rush to move to EF, unless you're just doing it purely out of interest. You're fine as you are for a good while yet :) – Mathew Thompson Apr 04 '12 at 20:22