Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
Where to put SQL statements in C# project?
I've googled on this topic, and have found quite a few answers, but either I didn't understand them or they didn't cover my situation. I'm a hobbyist develop and am just moving from Access/VBA to C#/SQL Server; while I"m slowly working through a (digital) pile of books on C#, SQL Server, and T-SQL on my kindle, I was hoping that the experts here could help me in the meantime.
My application uses quite a few SQL statements to populate list boxes, tree views, etc. In Access, I just included the SQL code in the form modules; it probably wasn't a good idea with Access, and probably even more so with C#, so I want to do things more properly in C#.
I have a few questions below, but first some context:
A) I'm not really concerned about enterprise-level best practice or performance--any application I develop will probably not be commercial at all, and if so, the dataset will be small enough that performance should not be an issue.
B) That said, I don't want to turn out crap or spaghetti code--whatever I do, I want to be high-quality, if not industry-standard or bleeding edge.
C) My biggest concern is actually simplicity; I'm teaching myself (OK, with your guidance) and I'm shooting with the minimum amount of brain damage consistent with the first two points. I'd also like to avoid dead-ends, where I spend weeks learning about some approach before deciding it is too complicated, etc. I'd like to learn simple, functional approaches and graduate to more complicated approaches later if necessary.
OK, here are the questions:
1) For now, I'm thinking about keeping it simple by just putting all of my SQL statements into one file in the C# project as named strings, and calling them from the forms. Does that make any sense? If so, how would I do it (ie, what kind of file should I put them in, and how would I call them)? FYI, I anticipate needing several dozen SQL statements, most not very complicated but some a bit involved.
2) From what I've read, some recommend keeping all of my SQL statements as stored procedures, which I understand are stored in SQL Server? But from what I've read stored procedures are more complicated than straight SQL and harder to maintain/troubleshoot. Is that correct? Any good reasons to move everything to stored procedures (or not)?
3) I've done a bit of reading on Entity Framework, and how it is "the future". Frankly it sounds like an interesting and potentially simpler approach and I've thought about moving in that direction, but I'm concerned that it could be too complicated for a beginner like me. Any recommendations?
My application uses quite a few SQL statements to populate list boxes, tree views, etc. In Access, I just included the SQL code in the form modules; it probably wasn't a good idea with Access, and probably even more so with C#, so I want to do things more properly in C#.
I have a few questions below, but first some context:
A) I'm not really concerned about enterprise-level best practice or performance--any application I develop will probably not be commercial at all, and if so, the dataset will be small enough that performance should not be an issue.
B) That said, I don't want to turn out crap or spaghetti code--whatever I do, I want to be high-quality, if not industry-standard or bleeding edge.
C) My biggest concern is actually simplicity; I'm teaching myself (OK, with your guidance) and I'm shooting with the minimum amount of brain damage consistent with the first two points. I'd also like to avoid dead-ends, where I spend weeks learning about some approach before deciding it is too complicated, etc. I'd like to learn simple, functional approaches and graduate to more complicated approaches later if necessary.
OK, here are the questions:
1) For now, I'm thinking about keeping it simple by just putting all of my SQL statements into one file in the C# project as named strings, and calling them from the forms. Does that make any sense? If so, how would I do it (ie, what kind of file should I put them in, and how would I call them)? FYI, I anticipate needing several dozen SQL statements, most not very complicated but some a bit involved.
2) From what I've read, some recommend keeping all of my SQL statements as stored procedures, which I understand are stored in SQL Server? But from what I've read stored procedures are more complicated than straight SQL and harder to maintain/troubleshoot. Is that correct? Any good reasons to move everything to stored procedures (or not)?
3) I've done a bit of reading on Entity Framework, and how it is "the future". Frankly it sounds like an interesting and potentially simpler approach and I've thought about moving in that direction, but I'm concerned that it could be too complicated for a beginner like me. Any recommendations?
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
I really like to put my sql statements into stored procedure (on the db level)
the application code then only needs to know the name of the stored procedure and the parameters to be passed
the application code then only needs to know the name of the stored procedure and the parameters to be passed
1) This creates an unnecessary coupling between your classes and components.
2) On the contrary. Having all SQL statements in on place, at the SQL Server, makes debugging and development simpler. You only need to think in layers.
3) It's already here. Just consider your situation: you need either to learn how to use SQL in C# correctly or how to use EF... I would go for EF.
2) On the contrary. Having all SQL statements in on place, at the SQL Server, makes debugging and development simpler. You only need to think in layers.
3) It's already here. Just consider your situation: you need either to learn how to use SQL in C# correctly or how to use EF... I would go for EF.
I'm with the above experts
>harder to maintain/troubleshoot.
I don't see this. You can always take a SP, comment out the CREATE/ALTER line, declare the @parameter variables, and execute in an ad-hoc debug mode.
Storing SQL in SP's means you can performance tune it, and store pre-generated execution plans. Can't do that with SQL passed in the application.
Impact Analysis, i.e. 'If I change this what will break?', is far easier if all T-SQL code is in one place (the database) instead of floating around hundreds of SSIS packages, SSRS reports, and C# / VB.Whatever applications.
>harder to maintain/troubleshoot.
I don't see this. You can always take a SP, comment out the CREATE/ALTER line, declare the @parameter variables, and execute in an ad-hoc debug mode.
I'm reading up on stored procedures as we speak, it does sound better than keeping the SQL in C# code; if I stick with SQL, sounds best to go with SPs. Given the context above, any reason not to?
On EF: you're right that if I need to teach myself something, I might be better off with EF, and I have the luxury, at least for now, of being able to do a "Code First" solution. My concern, however--based on some quick googling and an Amazon search--is that there seems to be much less information available about EF than, say, SQL server. Since books and internet searches are the basis of my "education", this would be a serious drawback if true.
Also, I can't really say that I understand what EF is or how it interacts with SQL Server (or indeed if I would even use SQL Server with EF); most of the info on the web dives into much more detail than is comprehensible for me.
On EF: you're right that if I need to teach myself something, I might be better off with EF, and I have the luxury, at least for now, of being able to do a "Code First" solution. My concern, however--based on some quick googling and an Amazon search--is that there seems to be much less information available about EF than, say, SQL server. Since books and internet searches are the basis of my "education", this would be a serious drawback if true.
Also, I can't really say that I understand what EF is or how it interacts with SQL Server (or indeed if I would even use SQL Server with EF); most of the info on the web dives into much more detail than is comprehensible for me.
OK, I was hoping for more comments, but I guess with the general questions this is what I'll get.
After spending the last couple of days looking at EF, I think I'll try it, at least for a few weeks to see how it turns out.
After spending the last couple of days looking at EF, I think I'll try it, at least for a few weeks to see how it turns out.
Thanks for the split. Good luck with your project. -Jim
>OK, I was hoping for more comments, but I guess with the general questions this is what I'll get.
Correct. Most experienced experts tend to shy away from open-ended questions, as we know there's a couple of iterations of requirements ellicitation before getting to the actual question, and we tend to have short attention spans.
If you have some spare time and want a few laughs check out my article Top 10 Ways to Ask Better Questions, and hit the 'Good Article' button if it generated a few giggles.
>OK, I was hoping for more comments, but I guess with the general questions this is what I'll get.
Correct. Most experienced experts tend to shy away from open-ended questions, as we know there's a couple of iterations of requirements ellicitation before getting to the actual question, and we tend to have short attention spans.
If you have some spare time and want a few laughs check out my article Top 10 Ways to Ask Better Questions, and hit the 'Good Article' button if it generated a few giggles.
Helpful article, thanks.
I'm still flailing around trying to decide on what approach to adopt but will certainly come back with more detailed questions once I've done a bit more reading and started playing around with my project. A bit nervous about tackling EF but if all goes well (hahaha) it sounds like it could be easier.
I'm still flailing around trying to decide on what approach to adopt but will certainly come back with more detailed questions once I've done a bit more reading and started playing around with my project. A bit nervous about tackling EF but if all goes well (hahaha) it sounds like it could be easier.
Far better to ask us these questions, as we're suckers for points, then ask your current employer and have them wonder why you're asking such questions..
Good luck.
Good luck.
then ask your current employer and have them wonder why you're asking such questions..
Maybe not stated in this thread, but I don't have a "current employer", I'm a hobbyist and do this for fun. It is very difficult to find answers to general questions on the web, that's why I've been seeking, sometimes in vain, help on this forum.
I'm not such an idiot that I'd be asking these questions if this was my full-time job...
Premium Content
You need an Expert Office subscription to comment.Start Free Trial