Gratulations, zk.net. Well said. aspdotnetv2, I strongly suggest you try to get some knowledge about what you talk BEFORE you talk about it. ALL of your points are wrong or based on outdated information, to a degree that is not even funny anymore. ::1. Performance
Wrong. Read the documentation. ::2. Ease of Maintenance Wrong. Given that you need to MANUALLY maintain a lot more routines, the argument is just wrong. ou seem to think that everyone not using stored procedures is so stupid to actually embedd his SQL all
over the place in the forms. THIS would be idiotic. And has nothing to do with SP's. Even when I was not using an O/R mapper I was already using dynamic SQL that was read from a configuration file. ONE place to maintain things. ::3. Data Layer separation Great.
Has nothing to do with the topic, though. Stored Prrocedures do not make the db into a data layer. Au contraire. ::3. Large/Binary data You mean 4, right? Now, guess what - I read multiu megabyte dynamic data with dynamic SQL. Read the documentation. ::If
you see Microsoft IBuySpy they use stored procedures extensively. Right. Microsoft is also the company that has a history of ignoring architecture. ::Also lot of companies have this standard. GREAT argument. Why do you not use Cobol? THere is STILL more program
code written in cobol (and in use) than code written in all other programming languages together. Can not be bad. I mean, there is SO much code written in it. Better we all use cobol again. ::If you search internet or news groups for the advantages of stored
procedures you will see ::lot more than what I mentioned. Yes. And you should realize that just by repeating wrong facts they do not turn into the truth. ::As there are more advantages than disadvantages it is better to use Stored Procedures # ::than embedded
SQL. Absoltuly. Now, hint: * I do NOT use embedded SQL. * I have not written any CRUD code in the last years. NONE. Zero. It is all generated on the fly. * Now THIS is easy to maintain, data layer separation, you know. Try using an O/R mapper once. You may
realize that there is a world out there that has advanced in the last 10 years. And your approach IS 10 years old.
Thank you all very much for your replies. WOW, these comments and links have really led me to a far greater understanding of this issue. An issue which clearly should not be decided on lightly and ill informed. As i stated in my original post coming from ADOc
and using updatebatch never caused any (major) problems, so the thought of writing all these extra stored procedures is alien to me and to think of all the extra development time required. So looking at ADO .NET and using the update command was my prefered
route but this route seems less flexible than the ADOc predecessor. In addition to being new to .NET development i assumed it was my lack of knowledge that was causing me to struggle with a clean divide between my business layer and data layer. However, your
comments and my initial reading is demonstrating the O/R mapper concept aids in providing that clean divide between the business and data layers. Once again, thank you for time and knowledge. Off to the web to clarify my understandings further. Kind regards
Scott
One think that is rarely mentioned in these forums is how quick and easy it is to generate stored procedures. So the argument of "1 column change equals 4 stored procedure changes" isn't a valid one in my opinion. Yes an OR mapper is better but development
time can be measured in years for a good one. Whereas a stored procedure generator can be knocked up in under a day.
<< Yes an OR mapper is better but development time can be measured in years for a good one. Whereas a stored procedure generator can be knocked up in under a day. >> so let someone else do the development for you. OR mappers range from $199 upwards with full
source... that's less than the cost of a day of development time where im from.
Yes, and the outcome is leages better than the result of: ::Whereas a stored procedure generator can be knocked up in under a day. Tip: saving time on the cost of infrastructure is a pretty bad move at times. The O/R mapper will give you a good architecutre,
while the SPÜ generatoe still leaves you with - a can of parts, architecture wise.
<< Tip: saving time on the cost of infrastructure is a pretty bad move at times. >> And sometimes it's a very good idea. All depends on what project you're working on. But getting back to my point, there are projects that for whatever reason (be it lack of
developer knowledge, a company that will not use 3rd party tools etc) using a stored procedure generator can be a very good thing. If the alternatives are a) Write you own O/R mapper b) Don't use a DAL c) Use a DAL but code it all manually d) Use a DAL and
have the stored procedures generated by code then I'd opt for d) every time.
This might be considered slighltly OT, but... Don't most O/R mappers execute sql as a stored procedure? I think it's called sp_execute or something like that. The question would be, does sql server store that stored p somewhere? I always thought that procedures
where "compiled", but if you just call sp_execute, does it compile the sql command that it's executing... ? By the way, what is "Don't use a DAL" supposed to mean? If even if you mix your layers together, you're still using Data Access if your app uses a database
or any other data source. I disagree as well with opting for part d, I think that you should write your own O/R mapper rather than have stored p's generated by code using ADO.NET or any other tool. Ultimately, it'll save time, in most cases that I've seen
anyway. Especially if your environment is such that you make data layer alterations consistently. I've done it both ways, and I just can't see why you'd want to have stored p's vs. an O/R mapper. If you're using some other tool that isn't ADO.NET to generate
them, then that's essentially a Data Access Generator of some sort, so why not go all the way? In addition, if you're working for a company that has policies against third party tools, I'd seek a new job where you can be given the freedom to not waste your
time as well as your employers' working on senseless, mundane, boring, tedious Data Access Code =)... !!!
<< Don't most O/R mappers execute sql as a stored procedure? I think it's called sp_execute or something like that. >> no, you've got it the wrong way round... sp_execute is a stored proc which executes a string as if it were inline sql. you can call sp_execute
from your own stored procs, if you need (for example) sql to be dynamically generated based on a parameter. o/r mappers use parameters, yes (rather than complete inline sql), but they're executing sql as text (usually). it is (can be) cached of course. p.s.
how did your cliff jump go? ;)
m7, Cliff jumping was a blast, fortunately, I brought a parachute with me... Unfortunately, since I was wrong about this again, I might have to jump this time, and leave the chute behind... =) Cheers, -A
<< In addition, if you're working for a company that has policies against third party tools, I'd seek a new job where you can be given the freedom to not waste your time as well as your employers' working on senseless, mundane, boring, tedious Data Access Code
=)... !!! >> Personally I don't have this problem but i was just pointing out that the good old O/R mapper is not ALWAYS the best solution. Maintaining a DAL which uses generated Stored Procedures takes very little time indeed if it's done correctly. Only
slightly more than maintaining the data that an O/R mapper needs to work in my experience.
thona
Member
20 Points
2923 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 04, 2004 07:28 PM|LINK
Scotty Boy
Member
270 Points
54 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 05, 2004 10:54 AM|LINK
Dave Wells
Member
310 Points
62 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 07, 2004 08:09 AM|LINK
m7
Contributor
4225 Points
843 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 07, 2004 09:11 AM|LINK
thona
Member
20 Points
2923 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 07, 2004 02:26 PM|LINK
Dave Wells
Member
310 Points
62 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 07, 2004 02:37 PM|LINK
boyd5
Participant
1033 Points
226 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 07, 2004 05:06 PM|LINK
Systems Architect
m7
Contributor
4225 Points
843 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 07, 2004 05:15 PM|LINK
boyd5
Participant
1033 Points
226 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 07, 2004 06:02 PM|LINK
Systems Architect
Dave Wells
Member
310 Points
62 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 08, 2004 08:00 AM|LINK