Linq + SQLMetal = Cool...
-
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:
-
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.
Agreed the update facility is brilliant. Actually I have to say I'm pretty impressed with EF. When LtoS came out I jumped on it and pretty much learnt on the fly (as I say porting out app), but this time (because the pressure is off), I've been doing a lot of reading and optimising along the way. I can understand why EF is a better choice in the long run, I just wish MS had let on that LtoS was a stop gap measure (as it now appears it was). Oh well you live and learn; the perils of early adoption :)
The only thing unpredictable about me is just how predictable I'm going to be.
-
Here was an issue I ran into with LINQ 2 SQL back with the Orca betas (which applies today): http://reflectedthought.com/TheCoder/archive/0001/01/01/Dark_Side_of_LINQ_2_SQL.aspx[^] And a little whining about another thing I wished they would have improved in LINQ 2 SQL, disconnected data without having to reread the data before updating it: http://reflectedthought.com/TheCoder/archive/0001/01/01/LINQ_Disconnected_Attach_no_Change_tracking_fix.aspx[^] Other than that, I like it. I have not looked much into LINQ 2 EF yet, but I am sure I will in the future. Right now though, I still use LINQ 2 SQL for my projects.
Rocky <>< Recent Blog Post: ViewState and SEO – Move it! Thinking about Silverlight? www.SilverlightCity.com
Just an observation... Reading your posts about LINQ hidden nasties, I realize these are exactly the issues I run into in Java JPA code. Java Persistence Api framework (which is behind all J2EE staff) seems to have been the inspiration for MS LINQ - the same ideas and the same problems. In my case, I ported the code to the plain old JDBC (had to write a simple code generator to make maintenance easier) - I could not rely on a framework that out of the blue tells me that an object should be detatched when I just created it, or it should be be mananged when I just read it from DB... And the CPU and memory usage were so high!
Rocky Moore wrote:
Other than that, I like it
I felt the same about JPA: couple of mouse clicks - and all your classes are created, and work like magic... well, most of the time ;)
-
I'm working on a linq project now. Trust me, the time you save by having MS do your data access code seem very small compared to the time you spend screaming at your IDE when something doesn't work and you have no idea as to why or what is wrong. I hate programming against a black box.
-
And no control of the generated SQL. Accessors for tables you don't need (I suspect). Will it do joins? I write SQL so I know what it's doing and only as much as I need. However, I've been listening to Saint Lennon today, so "Whatever gets you through the night".
You have TOTAL control of the generated code. You can use T4 templates to make the output code look however you want. It's built into VS2008... plenty of good info on it if you google it.