Linq + SQLMetal = Cool...
-
You do not have to go to SQLMetal, just add an LINQ to SQL Class to your project (you can have multiples too) and it will open up the designer. Switch to Server Explorer (View/Server Explorer), connect to the database and drag the tables you want onto the design surface. You can add relationships as you will and rename the objects it creates if you have a need. You can also drag a stored procedure over the the design seruver and it will create a method in the object class to call it with its parameters. Slick stuff! The classes it generates are all partial class types so you can add a new file to your project and extended those object classes such as display translations, business logic, etc. Really handy! Of course, this is just LINQ to SQL, LINQ itself works great for other objects and XML. It is a great general data query langauge that spans all data that are objects regardless of where you get the data. One word of caution though, in the beginning you need to watch carefully what is being sent to the server and when. With its lazy loading of objects, a simple query and walking through the data can generate hundreds, thousands or even tens of thousands of queries without you noticing. You have to take control on what is loaded and when. This is a step you already have to take care of manually in the old methods of data access, and for some new to LINQ to SQL, they think all that is automatic as they do not see it. We still have that responsiblity even though we do not notice it at first.
Rocky <>< Recent Blog Post: ViewState and SEO – Move it! Thinking about Silverlight? www.SilverlightCity.com
You may want to look into using the Entity Framework and Linq to Entities before investing time and energy to Linq to Sql. Microsoft basically said that they're not going to invest more energy in advancing it, and the Entity Framework should be what we use instead. Fortunately, the EF can be dragged and dropped VERY similar to how Rocky explained Linq to Sql works. http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx[^]
-
So here I am totally bogged down in reluctance to write more data access code and stored procedures. I hate it. It's tedious and bothersome. So... I google C# code generation SQL server and out pops this Linq result that talks about SQLMetal. Not having a clue at all what I'm looking at I bite. I open up the VS 2008 command prompt and type in:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC>sqlmetal /server:{server} /database:{db} /namespace:{new namespace} /code:{ClassName}.cs /language:csharp
I hit enter and think this won't work. What do you know... Out pops a huge monolithic class that has all of the stuff required to Create/Insert/Update/Delete every table in the DB all VIA Linq. {Scratches Head} How the heck do I use this? Turns out a quick Google search and *BOOM* it's out of the park. No inline SQL, no stored procedures and no boredom. It's all done. I just invoke the class, instance my table populate the fields and then it's time to "Smile and Waive" as I call Submit(). I'm now a Linq convert. I will never go back. :cool:
-
You may want to look into using the Entity Framework and Linq to Entities before investing time and energy to Linq to Sql. Microsoft basically said that they're not going to invest more energy in advancing it, and the Entity Framework should be what we use instead. Fortunately, the EF can be dragged and dropped VERY similar to how Rocky explained Linq to Sql works. http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx[^]
Yup, Was truly excellent news to hear about that exactly 2 days after I had ported our flagship application to LINQ to SQL. Thanks for that . However, that being said, I am quietly porting the app yet again to the Entity Framework and its not been too painful. Some methods that I used from LINQ to SQL (mainly SingleOrDefault) don't exist in EF so I have had to make some changes, but I'd say 80% of the code has ported unchaged. The majority has really been creating the EF equivelant of the dbml file and swapping out the creation code for creating the DataContext. I'm just glad I chose to access the data through an intermediary layer so none of the client code has been affected. As far as the OP is concerned (a question for those who are familiar with the designer approach), is this SqlMetal command line tool effectively a command line version of the designer or is there extra goodness I'd want to know about? Cheers
The only thing unpredictable about me is just how predictable I'm going to be.
-
I didn't keep all the generated code. I went in and cut out all the stuff I won't use. I paired about 60% of the mass out of the class. Now it's tight and lean and I've seen all the code too. Just because it hands you a blimp doesn't mean you have to keep it that way. As the documentation suggests it's meant to be a base that you then customize or extend to meet your own needs. Regardless... !SOLD!:rose: {Edit}:thumbsup: Honestly, you should check it out and look at the resulting code. It's not bad. It's strongly typed, field length is enforced and it's structured in a logical way that's usable, easy to modify/update and it will seriously save you a lot of time doing the heavy lifting for you. What it gives you can be changed in any way you see fit. I inherit it all into another class where I do some stuff to the values before they are passed and it's so easy to do. {/Edit}:thumbsup:
Welcome to the club! :) It's just too easy to things with LINQ, despite the various drawbacks.
'Howard
-
So here I am totally bogged down in reluctance to write more data access code and stored procedures. I hate it. It's tedious and bothersome. So... I google C# code generation SQL server and out pops this Linq result that talks about SQLMetal. Not having a clue at all what I'm looking at I bite. I open up the VS 2008 command prompt and type in:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC>sqlmetal /server:{server} /database:{db} /namespace:{new namespace} /code:{ClassName}.cs /language:csharp
I hit enter and think this won't work. What do you know... Out pops a huge monolithic class that has all of the stuff required to Create/Insert/Update/Delete every table in the DB all VIA Linq. {Scratches Head} How the heck do I use this? Turns out a quick Google search and *BOOM* it's out of the park. No inline SQL, no stored procedures and no boredom. It's all done. I just invoke the class, instance my table populate the fields and then it's time to "Smile and Waive" as I call Submit(). I'm now a Linq convert. I will never go back. :cool:
-
Hi I agree it's all cool, but i thought Linq to SQL was getting binned/de-supported/ignored? In favour of Entity Framework? Am I wrong? If nto, is it worth the investment? Dean
There is no investment. I just used it once for a project. It was cake. I cleaned it up. Made it pretty and used it. I've seen the comments on the Entity Framework. What is funny is the stuff I used is all Entity based which is confusing. So I think somehow I'm using the EF but anyway. I'll certainly investigate more. Just like everyone else. The key here is now that people know such things exist they will look for them and learn. Just like I'm doing. Had I not known then I would not have posted. Had I not posted then I would have taken much longer to learn about the EF. It's all good man.
-
Allow me to retort: Every application that was built with an ORM code generator off a database (and no huge amount of hand tweaking) has a crappy UI that should be taken out and shot, not inflicted on an unsuspecting public. Code Generation without heavy tweaking = crappy software, it's axiomatic. The correct and necessary way to store data in a database and the tasks that the end users need to accomplish are 180 degrees apart and the business objects in a well crafted easy to use application bear little resemblance to the database schema. Our whole job as developers is not just to develop software, it's to abstract away the inner workings of computers and software and present the end user with something that looks and works how they think. If you start below the UI with business objects that are a perfect reflection of the database then you are led down a path that ends with crazy forms with rank upon rank of what are basically database fields exposed directly in the UI and a bunch of pointless extra work and confusion for the end user. People don't need developers for that, they can just hire a sql admin to make a database and users can just enter in the data in the tables directly. The point of being a developer is to be a crafstman who uses a combination of skill, and artistic ability to make the connection between the reality of the end users tasks they need to accomplish throughout their day and the separate reality of how data should be stored in a database. If you say you're using code generation for the heavy lifting then going back and heavily re-tweaking it for anything of consequence then that's fine but if you're generating the code then going on to the interface you're building a foundation on quicksand. And if you really are planning on hand tweaking LINQ has to be about the worst abomination to inflict upon yourself to no useful purpose I can imagine. Dense, unreadable, unmaintainable.... X|
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
Shoot, I can't vote 11?
-
Hey! You converted me too! Nice stuff. However I resent this comment in the top of the resulting .cs-file: "// This code was generated by a tool." ...
Indeed, but I recall meeting a (COBOL) developer many years ago, his name was Atul.
-
I'm in a scrappy mood. I'm mostly serious about what I'm saying but I'm also having some fun too. Keep that in mind. :-\ Oh. Okay. Well you better quit using .Net because in case you haven't noticed... it's generated code written by the same guys. I'm not Elvis but I am letting this one go. Just doesn't mean that much to me at all. By the way I didn't vote you down either. I don't vote at all unless it's a 5. I never low vote. Anyway, if that's your battle cry head to war. I'll watch from the distance while I eat with my family and relax. The thing that kills me is you have zero clue how I'm using the code. God no I'm not parking a UI right on top of it. The UI hasn't even been written yet. The only thing I'm using it for is a data layer and that's it. I just wanted a simple class I could invoke to save to the DB. I'm so far away from building a UI it's not even funny. Yet you seem to assume that somehow I bound controls to the generated class and called it an application. Sorry. Haven't done that since... uh well I've uh never done that. Your whole tone is condescending like you are some all knowing wise man sitting on top of your golden mountain populated with coffee beans that you fart out of nothing. You don't have a clue what I'm doing. How I'm doing it or anything else. You start off about things like cocaine and sand and it makes no sense at all. Try asking more questions. Try actually understanding what a person is doing. Make sure you fully grasp what it is they are attempting and how it is they are attempting it. At that point make a suggestion but please don't pass judgment like some arcane ruler that sits on a cloud. It's annoying.
:-D
code-frog wrote:
I just wanted a simple class I could invoke to save to the DB.
I think it's a pretty natural assumption to assume that someone who is bothering to generate code in the first place is doing quite a bit more than making a little utility class.
code-frog wrote:
The only thing I'm using it for is a data layer and that's it
That's how it starts, unfortunately the whole design is fundamentally broken at exactly this point, there's no where to go from here but wrong turns. At the risk of using another analogy it's like starting a trip to mars with your initial vector off .0001 degrees, by the time you get to the other end you've missed Mars completely.
code-frog wrote:
Your whole tone is condescending like you are some all knowing wise man sitting on top of your golden mountain populated with coffee beans that you fart out of nothing.
:) Ah well I guess decades of success in the industry doesn't count for anything these days. I feel like I am qualified to make a case against code generation because I make huge commercial business apps that are very sucessful and I've tried and adopted every possible method to speed that process up while still putting out sellable software in a timely fashion; if code generation made any kind of sense I'd be the first guy in line to get some.
code-frog wrote:
At that point make a suggestion but please don't pass judgment like some arcane ruler that sits on a cloud. It's annoying.
I'm sure it is annoying, doubly so when you know I'm right and have doubts about it yourself but initially wrote such a glowing endorsement of it that you have no room to go anywhere else with it. ;) Do what you want, I was only trying to help those with less experience that might take code generation seriously for anything that matters. :rose:
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
-
The only problem I have with LINQ is it came out in ASP.NET 3.5 and my Windows customers are still on ASP.NET 2.0. :sigh: Some day I will get to use it but unfortunately not right now.
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopesAlthough you can create a seperate project targeted for .Net 3.5 framework, for your data accesss layer that uses LINQ to SQL and reference that in your ASP 2.0 web site project. When you reference the .Net3.5 data access assembly the ASP 2.0 web site will warn you, but you can ignore that use the assembly with no problem. Keep in mind you deployment web server should have .Net 3.5 installed. I have done this in one of the projects and worked out nicely.
-
I didn't keep all the generated code. I went in and cut out all the stuff I won't use. I paired about 60% of the mass out of the class. Now it's tight and lean and I've seen all the code too. Just because it hands you a blimp doesn't mean you have to keep it that way. As the documentation suggests it's meant to be a base that you then customize or extend to meet your own needs. Regardless... !SOLD!:rose: {Edit}:thumbsup: Honestly, you should check it out and look at the resulting code. It's not bad. It's strongly typed, field length is enforced and it's structured in a logical way that's usable, easy to modify/update and it will seriously save you a lot of time doing the heavy lifting for you. What it gives you can be changed in any way you see fit. I inherit it all into another class where I do some stuff to the values before they are passed and it's so easy to do. {/Edit}:thumbsup:
I don't think I would bother about cleaning up the generated code as the next time you run Sql Metal you will obviously lose all your changes. Just treat it like the resx files they do the job. Do however look into creating partial classes to create your own custom/business type logic for each table(s). Also DEFINATELY get LinqPad
-
Yup, Was truly excellent news to hear about that exactly 2 days after I had ported our flagship application to LINQ to SQL. Thanks for that . However, that being said, I am quietly porting the app yet again to the Entity Framework and its not been too painful. Some methods that I used from LINQ to SQL (mainly SingleOrDefault) don't exist in EF so I have had to make some changes, but I'd say 80% of the code has ported unchaged. The majority has really been creating the EF equivelant of the dbml file and swapping out the creation code for creating the DataContext. I'm just glad I chose to access the data through an intermediary layer so none of the client code has been affected. As far as the OP is concerned (a question for those who are familiar with the designer approach), is this SqlMetal command line tool effectively a command line version of the designer or is there extra goodness I'd want to know about? Cheers
The only thing unpredictable about me is just how predictable I'm going to be.
Yeah, sorry about that man. Apparently a lot of people are in your shoes. By the way though, you probably already figured it out, but the equivalent of Single/SingleOrDefault is First/FirstOrDefault in EF. I'm not sure why they did that...One very cool difference with LtoS is that the EF has an "update from database" wizard that LtoS didn't have. With LtoS you would have had to re-drag and drop everything you wanted all over again. On the other hand, you can right-click within the EF designer UI and click on "update model from database". So I know that is at least 1 thing that sqlmetal (or LtoS as a whole for that matter) cannot do.
-
:-D
code-frog wrote:
I just wanted a simple class I could invoke to save to the DB.
I think it's a pretty natural assumption to assume that someone who is bothering to generate code in the first place is doing quite a bit more than making a little utility class.
code-frog wrote:
The only thing I'm using it for is a data layer and that's it
That's how it starts, unfortunately the whole design is fundamentally broken at exactly this point, there's no where to go from here but wrong turns. At the risk of using another analogy it's like starting a trip to mars with your initial vector off .0001 degrees, by the time you get to the other end you've missed Mars completely.
code-frog wrote:
Your whole tone is condescending like you are some all knowing wise man sitting on top of your golden mountain populated with coffee beans that you fart out of nothing.
:) Ah well I guess decades of success in the industry doesn't count for anything these days. I feel like I am qualified to make a case against code generation because I make huge commercial business apps that are very sucessful and I've tried and adopted every possible method to speed that process up while still putting out sellable software in a timely fashion; if code generation made any kind of sense I'd be the first guy in line to get some.
code-frog wrote:
At that point make a suggestion but please don't pass judgment like some arcane ruler that sits on a cloud. It's annoying.
I'm sure it is annoying, doubly so when you know I'm right and have doubts about it yourself but initially wrote such a glowing endorsement of it that you have no room to go anywhere else with it. ;) Do what you want, I was only trying to help those with less experience that might take code generation seriously for anything that matters. :rose:
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
Just a couple of side questions John C, yet pertinent. Out of curiosity, have you used the EF before to know what it's capable of? You know about ESQL? Perhaps most importantly, do you know that one of its flagship differences between itself and Linq to Sql is that it doesn't have to be a 1-to-1 relationship between the code and the database schema? Or even for that matter, do you know how many enterprise projects were created with a foundation of the likes of Hibernate or NHibernate? Some things are obviously wrong (nsquared sorting) and some things are obviously right (coding caching for your data access). But everybody has their own styles of coding. To say that code-generation is crappy or wrong without tweaking it so much that it was pointless in generating it in the first place, is indeed painting with quite a wide brush.
-
Just a couple of side questions John C, yet pertinent. Out of curiosity, have you used the EF before to know what it's capable of? You know about ESQL? Perhaps most importantly, do you know that one of its flagship differences between itself and Linq to Sql is that it doesn't have to be a 1-to-1 relationship between the code and the database schema? Or even for that matter, do you know how many enterprise projects were created with a foundation of the likes of Hibernate or NHibernate? Some things are obviously wrong (nsquared sorting) and some things are obviously right (coding caching for your data access). But everybody has their own styles of coding. To say that code-generation is crappy or wrong without tweaking it so much that it was pointless in generating it in the first place, is indeed painting with quite a wide brush.
oooshola wrote:
To say that code-generation is crappy or wrong without tweaking it so much that it was pointless in generating it in the first place, is indeed painting with quite a wide brush.
Yeah the brush of truth. :) I sincerely and with hand on heart think code generation as well as LINQ are in the same class of developer productivity tools that provide no benefit to the end user, quite the opposite, and that's what software development is all about: the end user. We're supposed to be craftsmen, skilled engineers, if we keep shooting ourselves in the face with all these tools that make our lives easier but lead to worse and worse software where are we in the equation when you follow that to it's conclusion? Outsourced, commoditized, left to the cheapest bidder. I know it's too late, we've already given up at every opportunity for the siren song of convenience and metrics and every other bullshit methodology that was crammed down our throats but at some point we need to collectively grow a pair and say enough is enough. Good software is designed and developed from the top down. It first and foremost satisfies the real world tasks that the user needs to accomplish in a way that fits naturally with how the user thinks and acts and the environment they work in. Once the tasks are identified then the design can begin and it starts with the user interface *then* the business objects below the interface, then the database technology independent data access layer and only then can the database schema be designed and implemented. Sure there may be some minor layers in there between but that's the gist of it. This is what a craftsman does, it can't be done automatically by a machine, it's our very purpose for existence. Code generation tools fit naturally into the mindset of developers that do bottom up development. They analyze what data and objects the user is working with, whip up a database schema and work their way up. At no point do they really look at it as task oriented design. The end result is a UI that is not abstracted enough or at all from the data that the user is working with. It doesn't flow for the user, it's a bunch of data to be filled in and worked with, not a way to accomplish the tasks that they need to get done. It's lazy, thoughtless and can be done by any idiot who knows how to use a mouse and a keyboard and has the right tools. There's nothing beautiful about programs created this way, they are not ele
-
oooshola wrote:
To say that code-generation is crappy or wrong without tweaking it so much that it was pointless in generating it in the first place, is indeed painting with quite a wide brush.
Yeah the brush of truth. :) I sincerely and with hand on heart think code generation as well as LINQ are in the same class of developer productivity tools that provide no benefit to the end user, quite the opposite, and that's what software development is all about: the end user. We're supposed to be craftsmen, skilled engineers, if we keep shooting ourselves in the face with all these tools that make our lives easier but lead to worse and worse software where are we in the equation when you follow that to it's conclusion? Outsourced, commoditized, left to the cheapest bidder. I know it's too late, we've already given up at every opportunity for the siren song of convenience and metrics and every other bullshit methodology that was crammed down our throats but at some point we need to collectively grow a pair and say enough is enough. Good software is designed and developed from the top down. It first and foremost satisfies the real world tasks that the user needs to accomplish in a way that fits naturally with how the user thinks and acts and the environment they work in. Once the tasks are identified then the design can begin and it starts with the user interface *then* the business objects below the interface, then the database technology independent data access layer and only then can the database schema be designed and implemented. Sure there may be some minor layers in there between but that's the gist of it. This is what a craftsman does, it can't be done automatically by a machine, it's our very purpose for existence. Code generation tools fit naturally into the mindset of developers that do bottom up development. They analyze what data and objects the user is working with, whip up a database schema and work their way up. At no point do they really look at it as task oriented design. The end result is a UI that is not abstracted enough or at all from the data that the user is working with. It doesn't flow for the user, it's a bunch of data to be filled in and worked with, not a way to accomplish the tasks that they need to get done. It's lazy, thoughtless and can be done by any idiot who knows how to use a mouse and a keyboard and has the right tools. There's nothing beautiful about programs created this way, they are not ele
Ok, so I gather the answer to my questions are all "no"? First and foremost I'm not telling you what the 1 way to program is. I'm in fact stating the opposite, by respecting your *style* of coding, as I stated already in my first post. And by style, I'm referring to your abstinence from ORMs, not your top-down approach (i.e. top-down is not just a style). I agree with the end-user oriented and top-down approaches, and practice it myself (in fact I'm a graphic designer as well--the first thing I do when building a web app for instance, is to actually fire up Photoshop--not VS--and sit with the client). So I agree that starting with data is a very bad idea. However, I completely disagree that ORMs are mutually exclusive with the top-down approach. Correct me if I misunderstand you, but it seems that you think that 2 apps that have the same exact well-designed front end cannot have different data layers with 1 being written from scratch, and 1 using an ORM. The objects you get from ORMs are simply your data access layer. The business layer that is written by ourselves creates the level of abstraction in which the UI can be completely ignorant of how the data layer works--whether the data layer was from scratch or not. So here's the difference. When it *is* finally time to write the data layer, some people prefer to write it completely from scratch, some prefer incorporating an ORM. It depends on what your comfortable with, not if you're "an idiot" or not. An idiot will write bad code from scratch, or with an ORM, and so the contrapositive is true as well. This is why I say these particular things are really style--which each craftsmen uniquely has. My own opinion is that when an ORM is used correctly, I find myself completing/expanding the data layer faster. This speed in completing and updating the project in turn actually does directly benefit the end-user.
-
Although you can create a seperate project targeted for .Net 3.5 framework, for your data accesss layer that uses LINQ to SQL and reference that in your ASP 2.0 web site project. When you reference the .Net3.5 data access assembly the ASP 2.0 web site will warn you, but you can ignore that use the assembly with no problem. Keep in mind you deployment web server should have .Net 3.5 installed. I have done this in one of the projects and worked out nicely.
Excellent! Thanks for the information. I will have to do that. :-D
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
Ok, so I gather the answer to my questions are all "no"? First and foremost I'm not telling you what the 1 way to program is. I'm in fact stating the opposite, by respecting your *style* of coding, as I stated already in my first post. And by style, I'm referring to your abstinence from ORMs, not your top-down approach (i.e. top-down is not just a style). I agree with the end-user oriented and top-down approaches, and practice it myself (in fact I'm a graphic designer as well--the first thing I do when building a web app for instance, is to actually fire up Photoshop--not VS--and sit with the client). So I agree that starting with data is a very bad idea. However, I completely disagree that ORMs are mutually exclusive with the top-down approach. Correct me if I misunderstand you, but it seems that you think that 2 apps that have the same exact well-designed front end cannot have different data layers with 1 being written from scratch, and 1 using an ORM. The objects you get from ORMs are simply your data access layer. The business layer that is written by ourselves creates the level of abstraction in which the UI can be completely ignorant of how the data layer works--whether the data layer was from scratch or not. So here's the difference. When it *is* finally time to write the data layer, some people prefer to write it completely from scratch, some prefer incorporating an ORM. It depends on what your comfortable with, not if you're "an idiot" or not. An idiot will write bad code from scratch, or with an ORM, and so the contrapositive is true as well. This is why I say these particular things are really style--which each craftsmen uniquely has. My own opinion is that when an ORM is used correctly, I find myself completing/expanding the data layer faster. This speed in completing and updating the project in turn actually does directly benefit the end-user.
Hmmm..sounds like we're talking about different things here. I think you're talking about is an extra layer that I don't use or have that resides immediately above the database itself and below the business object layer. I'm talking about ORM tools that generate the business objects from the database schema.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
-
Ashley van Gerven wrote:
A major gripe of mine with Linq 2 SQL is that you cannot update a single table from the DB (using sqlmetal or VS). You have to regenerate the entire class (i.e. all tables).
How is it you have to regenerate classes for all tables within VS? When you select a LINQ 2 SQL class, it will bring up the designer on which you can place a single table in a class. Perhaps you are referring to updating a table without generating any class?
Rocky <>< Recent Blog Post: ViewState and SEO – Move it! Thinking about Silverlight? www.SilverlightCity.com
Ah yes - you can drag a table on again, but IIRC then you have to recreate any relationships that you configured in VS. Whereas with Entity Framework you can just refresh a table, which is easier.
-
Ah yes - you can drag a table on again, but IIRC then you have to recreate any relationships that you configured in VS. Whereas with Entity Framework you can just refresh a table, which is easier.
Ashley van Gerven wrote:
recreate any relationships that you configured in VS. Whereas with Entity Framework you can just refresh a table, which is easier.
Yes, this is true, they never got around to adding that feature in VS. Of course, if they relationships exist at the database level though, they will be recretated when you re-drop the table(s) again. As far as I can see though, it appears EF still has a long way to go if a person plans to use stored procedures. It is nice having LINQ 2 SQL generate the objects based on the return of the procedures. Of course, have to hand work it if they return multiple result sets, but at least the functionality is there.
Rocky <>< Recent Blog Post: ViewState and SEO – Move it! Thinking about Silverlight? www.SilverlightCity.com
-
So here I am totally bogged down in reluctance to write more data access code and stored procedures. I hate it. It's tedious and bothersome. So... I google C# code generation SQL server and out pops this Linq result that talks about SQLMetal. Not having a clue at all what I'm looking at I bite. I open up the VS 2008 command prompt and type in:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC>sqlmetal /server:{server} /database:{db} /namespace:{new namespace} /code:{ClassName}.cs /language:csharp
I hit enter and think this won't work. What do you know... Out pops a huge monolithic class that has all of the stuff required to Create/Insert/Update/Delete every table in the DB all VIA Linq. {Scratches Head} How the heck do I use this? Turns out a quick Google search and *BOOM* it's out of the park. No inline SQL, no stored procedures and no boredom. It's all done. I just invoke the class, instance my table populate the fields and then it's time to "Smile and Waive" as I call Submit(). I'm now a Linq convert. I will never go back. :cool: