Shamil Salakhetdinov
shamil at users.mns.ru
Sun Oct 16 06:47:14 CDT 2005
<<< > http://www.mygenerationsoftware.com/portal/dOOdads/Overview/tabid/63/Default.aspx >>> Thank you, Gustav. I did look through it but I didn't yet decide will I give it a try ot not - MS DLINQ looks like a "killer" of most of O-R mapping tools and frameworks (I can be wrong). Here is a discussion on this topic: http://www.theserverside.net/news/thread.tss?thread_id=36866 with this exerpt about LINQ approach, which I think is correct: <<< This prudent, bottom-up approach contrasts sharply with coming up with a top-down approach where one attempts to design a universal framework that pretend to do everything : 1) Abstact any operations on every database in the world 2) Deal intelligently with data caching 3) Perform real-time optimizations on database access 4) integrates nicely with existing data stores 5) implements anti-gravitation 6) brings peace on earth 7) solves the global warming problem, etc. It is very hard, maybe impossible to come up with an universal framework that attempts to solve every DB problem on earth. Proof is that, in the past, whenever someone attempted to come up with such universal frameworks, either they either got burned badly, or the resulting framework was too slow compared with native database access, or they had to focus only specific products. The trouble usually starts when you want to implement efficient DB applications. I believe in an evolutionary approach on all these concepts. LINQ offers a nice framework for queries (you can add updates too on top of that - but my personal take is that's not the innovative part). >>> <<< ...though I have to admit that my patience is not to read all the comments carefully. >>> And I did find time to read them all today :) I think now these comments have almost everything to make the right design decision for a certain development task. A kind of the only resource a developer may need :) Here are some interesting IMO excertps: <<< "I'll define two kinds of stored procedures: a) (long-running) data-processing procedures and b) CRUD procedures." [snip] "Category a) is the category of which I think it has a reason to exist" [snip] "The other category, b), is IMHO the category of procedures which should be avoided." >>> <<< Does my vested interest have merits in this discussion? Ok, I'll tell you something. I funded the development of LLBLGen Pro myself, during 2003. It was suppose to be a stored procedure oriented toolkit, just as its predecessor is (did you know Peter, I did write a stored procedure generator which is used by tens of thousands of .NET developers worldwide?). During development it turned out this was not going to work, as tests with O/R mapper code showed it was far more productive and could live up the speed or was even faster. I had to throw away 3 months of self-funded work out the window. Because of that I almost didn't have enough funding to make the whole track. Do you really think I'm against procs just because I have vested interest? No, I learned the hard way it isn't the way to go in a lot of situations, or better formulated: today there are other ways for doing data-access than solely CRUD procs. And there are a lot of O/R mapper tools today, if people want to try one, or use one, they can pick a free one today and get busy and see for themselves. The funny thing is that this discussion is non-existing in the Java-world. I can give you 1 reason why: MS doesn't like O/R mapping. Don Box called it "the vietnam of Computer Science". Windows developers look at MS what to do in general. MS sells SqlServer, they want to keep DBA's happy, procs are a cornerstone of their marketing policy for SqlServer. An O/R mapper doesn't sell SqlServer, as most of the time you can flip a switch and your app works on Oracle. You quoted an Objectspaces marketing snippet to proof your point. When I read that quote I really knew you don't get it: MS marketing around Objectspaces has been flaky at best, because it was a technology which wasn't supporting the core business policy, and their positioning (which you quoted) is marketing blabla. Is marketing goo today's standard developers should do check with to see if they do their job OK? >>> <<< So, what if MS comes rumbling one day with ObjectSpaces that does not generate SPs to do its stuff? Will we forget about SPs? I bet we will, easy as peanuts! >>> <<< Entirely untrue; have you looked at how easy MS made automating CRUD operations via ADO.NET datasets, compared to the previous technologies (ODBC/OLE DB/ADO) that were available? MS, it appears, wants to let developers code CRUD in the DAL using their language of choice. >>> <<< I don't think you can make an exclusive decision, but you have to pick what best fits your needs, which isn't as easy as it sounds. I wish there was a clear cut right/wrong answer as it would make things a little easier. I really like the idea of the OR/M and PQs, but I am afraid of opening up complete table access to users. While most users wouldn't even know how to connect to a database from a 3rd party application, it would only take one to mess things up. If you are lucky enought to be able to lock down your app with an application role password, then I don't think it would be as bad. >>> Shamil ----- Original Message ----- From: "Gustav Brock" <Gustav at cactus.dk> To: <accessd at databaseadvisors.com> Sent: Saturday, October 15, 2005 2:46 PM Subject: Re: [AccessD] Data interface The best way > Hi Shamil > > Thanks for these links, though I have to admit that my patience is not to read all the comments carefully. > > I still believe it can be a nightmare to maintain SPs - because you easily end up with incompatible versions of frontend(s) and database - thus these should be kept to basic features of the database and not for sophisticated business rules. But as always, it depends ... > > However, I noticed this link: > > http://www.mygenerationsoftware.com > > and its interesting dOOdads: > > http://www.mygenerationsoftware.com/portal/dOOdads/Overview/tabid/63/Default.aspx > > "an elegant .NET architecture available in C# and VB.NET and capable of supporting any .NET managed data provider." > "Currently dOOdads are available for Microsoft SQL, Oracle, Firebird, Access, PostgreSQL, VistaDB, SQLite, and MySQL." > > And for the DNN (DotNetNuke) fans: > > http://scottschecter.net/Projects/dOOdadsOnDNN/tabid/84/Default.aspx > > /gustav <<< tail trimmed>