LINQ and the future of database design/programming
-
DLinq is a big mess[^] What's wrong with DLinq? Here's the list I have so far: attribute-based, MS Sql Server only, overly complicated, poor stored proc support, no server-side paging, very limited functionality, and no WinFS/OPath integration. I've commented on why attributes are superior to attributes before, and others are already chiming in on this, so I'm simply going to point out that they've failed in delivering their own goal to be "non-intrusive", which is stated in the DLinq docs. Next, while many people don't care about being able to simultaneously targetting multiple databases, its also very true that many people that target only one database do NOT work with MS Sql Server! DLinq is needlessly complex because it actually expects you to know a lot more than just ADO.NET and Sql, much like XLinq expects too much Xml knowledge. Consider their example query "from c in db.Customers where c.City == 'London' select c;" -- note that db.Customers only works because they have elsewhere defined Customers as a Table type. But you've already marked your Customer class with the attribute "Table(Name = 'Customers')", not too mention all the Column attributes -- so why isn't the attribute enough to make it clear what "Customers" refers to? etc. I'm beginning to sound like a broken record, but: 1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance. 2. I fundamentally disagree with entangling the schema with the UI presentation via tables. That's what views (and why they are called views) are for. They allow me to modify the schema without rewriting the visualization code. 3. I fundamentally disagree with interactions in application code that entangles non-abstracted (table again rather than view) schema with application-specific code. Again, change the schema, change the code. It creates brittle applications. 4. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code. 5. I'm not a fan of stored procedures, so for me, that's not an acceptable alternative. The only possible place that DLinq makes sense is in business rules, and then it still only makes sense of you'
I too believe LINQ has a small future. And if there is a bet to make I'd put my money on the ms entity framework. It turns out that MS proprietary ideeas are usually poor, but when they inspire from other products like those from Sun or Oracle, they manage to outrun the competition. So, considering that the MS Entity Framework is not an "entirely" MS concept we might see something very nice there.
Alex C. D.
-
DLinq is a big mess[^] What's wrong with DLinq? Here's the list I have so far: attribute-based, MS Sql Server only, overly complicated, poor stored proc support, no server-side paging, very limited functionality, and no WinFS/OPath integration. I've commented on why attributes are superior to attributes before, and others are already chiming in on this, so I'm simply going to point out that they've failed in delivering their own goal to be "non-intrusive", which is stated in the DLinq docs. Next, while many people don't care about being able to simultaneously targetting multiple databases, its also very true that many people that target only one database do NOT work with MS Sql Server! DLinq is needlessly complex because it actually expects you to know a lot more than just ADO.NET and Sql, much like XLinq expects too much Xml knowledge. Consider their example query "from c in db.Customers where c.City == 'London' select c;" -- note that db.Customers only works because they have elsewhere defined Customers as a Table type. But you've already marked your Customer class with the attribute "Table(Name = 'Customers')", not too mention all the Column attributes -- so why isn't the attribute enough to make it clear what "Customers" refers to? etc. I'm beginning to sound like a broken record, but: 1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance. 2. I fundamentally disagree with entangling the schema with the UI presentation via tables. That's what views (and why they are called views) are for. They allow me to modify the schema without rewriting the visualization code. 3. I fundamentally disagree with interactions in application code that entangles non-abstracted (table again rather than view) schema with application-specific code. Again, change the schema, change the code. It creates brittle applications. 4. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code. 5. I'm not a fan of stored procedures, so for me, that's not an acceptable alternative. The only possible place that DLinq makes sense is in business rules, and then it still only makes sense of you'
Marc Clifton wrote:
1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance.
Actually, can can pull mix/match any data you want in any shape you want. After all, LINQ 2 SQL is basically for use in your data layer (if you are smart, you do not want actual query building outside the data layer) where data to and from the database is handled. You can cram that data into any kind of object you like. You can even then use Linq to access, search and pull data from any of those objects if you like. Of course, there are times when you do not have enough of an applciation to bother with a data layer and you can easily and quickly use Linq 2 SQL for hooking up your data. Yes, that moves it to the persentation layer, but if you just need a quick form or a quick report and do not care about abstraction.
Marc Clifton wrote:
4. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code. 5. I'm not a fan of stored procedures, so for me, that's not an acceptable alternative.
Then how do you plan for your data layer to communicate with your database that does have data stored in tables or in views (a dynamic table)? You either use SQL or Sprocs, what is the option here? There are some short Linq 2 SQL videos that give a bit of overview, but the one that really got me thinking was the "Inheritance" video using discriminators, that I thought was pretty cool. http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2007/05/10/9322.aspx[^] Another interesting part of using Linq 2 SQL is that you can make use of the deferred execution in some apps, where the data is not even actually pulled from the database until it is enumerated. This is like passing a datareader without all the headaches. Works great for building a web page output to a grid or something like that. I know, the short time I have worked with Linq 2 Sql, it is really cleaning up my data layer and making it much more flexible in pulling in data and there are more features on the way.
-
Rohde wrote:
I almost get the feeling that this could be a very big thing
It's natural and beautiful, can't wait for .net 3.5
P Think of the environment; please don't print this message unless you really need to.
With ya Norm! It sure is cleaning up my data layers and making it much easier to keep track of things!
Rocky <>< Latest Code Blog Post: Linq - One-to-One issues? Latest Tech Blog Post: Microsoft Surface!
-
Marc Clifton wrote:
1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance.
Actually, can can pull mix/match any data you want in any shape you want. After all, LINQ 2 SQL is basically for use in your data layer (if you are smart, you do not want actual query building outside the data layer) where data to and from the database is handled. You can cram that data into any kind of object you like. You can even then use Linq to access, search and pull data from any of those objects if you like. Of course, there are times when you do not have enough of an applciation to bother with a data layer and you can easily and quickly use Linq 2 SQL for hooking up your data. Yes, that moves it to the persentation layer, but if you just need a quick form or a quick report and do not care about abstraction.
Marc Clifton wrote:
4. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code. 5. I'm not a fan of stored procedures, so for me, that's not an acceptable alternative.
Then how do you plan for your data layer to communicate with your database that does have data stored in tables or in views (a dynamic table)? You either use SQL or Sprocs, what is the option here? There are some short Linq 2 SQL videos that give a bit of overview, but the one that really got me thinking was the "Inheritance" video using discriminators, that I thought was pretty cool. http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2007/05/10/9322.aspx[^] Another interesting part of using Linq 2 SQL is that you can make use of the deferred execution in some apps, where the data is not even actually pulled from the database until it is enumerated. This is like passing a datareader without all the headaches. Works great for building a web page output to a grid or something like that. I know, the short time I have worked with Linq 2 Sql, it is really cleaning up my data layer and making it much more flexible in pulling in data and there are more features on the way.
Rocky Moore wrote:
You either use SQL or Sprocs, what is the option here?
I post the transactions up to the middleware server. As the transactions are processed, server-side business rules can be triggered on the field and row changes (like SQL triggers, but running in .NET not in the server, albeit possibly becoming moot given the .NET support in SQL 2005). The middleware server then dynamically generates the appropriate SQL and updates the DB.
Rocky Moore wrote:
but the one that really got me thinking was the "Inheritance" video using discriminators
Thanks! I'll watch it in a bit.
Rocky Moore wrote:
I know, the short time I have worked with Linq 2 Sql, it is really cleaning up my data layer and making it much more flexible in pulling in data and there are more features on the way.
You should write an article on "before" and "after". Marc
-
DLinq is a big mess[^] What's wrong with DLinq? Here's the list I have so far: attribute-based, MS Sql Server only, overly complicated, poor stored proc support, no server-side paging, very limited functionality, and no WinFS/OPath integration. I've commented on why attributes are superior to attributes before, and others are already chiming in on this, so I'm simply going to point out that they've failed in delivering their own goal to be "non-intrusive", which is stated in the DLinq docs. Next, while many people don't care about being able to simultaneously targetting multiple databases, its also very true that many people that target only one database do NOT work with MS Sql Server! DLinq is needlessly complex because it actually expects you to know a lot more than just ADO.NET and Sql, much like XLinq expects too much Xml knowledge. Consider their example query "from c in db.Customers where c.City == 'London' select c;" -- note that db.Customers only works because they have elsewhere defined Customers as a Table type. But you've already marked your Customer class with the attribute "Table(Name = 'Customers')", not too mention all the Column attributes -- so why isn't the attribute enough to make it clear what "Customers" refers to? etc. I'm beginning to sound like a broken record, but: 1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance. 2. I fundamentally disagree with entangling the schema with the UI presentation via tables. That's what views (and why they are called views) are for. They allow me to modify the schema without rewriting the visualization code. 3. I fundamentally disagree with interactions in application code that entangles non-abstracted (table again rather than view) schema with application-specific code. Again, change the schema, change the code. It creates brittle applications. 4. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code. 5. I'm not a fan of stored procedures, so for me, that's not an acceptable alternative. The only possible place that DLinq makes sense is in business rules, and then it still only makes sense of you'
Hello, >>1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance.<< How else are you going to do it?? If you embed data access code within the GUI presentation code, then when you make an ASP.Net version of that nifty windows forms app, you have to copy the code and maintain it in 2 places. What if you change the database underneath or even keep the database but access it through a web service (scaling it up)? What if you need data from both an SQL Database and aan XML file? I think its better to have a database layer , a business layer and a presentation layer. The business layer lets you fiddle with the incomming data before delivering a consistant picture the presentaion layer. if you have this layer then the presenation layer can only get either a modified dataset or a strongly type class with field names specified.(How else??) (In fact all the presentaion layer may do is bind the gui controls to the business layer classes) I think this gives you the best longterm maintenance/development mix , which is surely worth a little extra pain at the begining. And dont forget the code reuse possibilities at the database layer . It could receive a command in "standard" Query and convert it to the correct format needed by whatever database/file/whatever is needed. New format means adding a class to the database layer - Once! Indeed if you have a standarad business layer class and then derive individual classes for the data entities (ie employees or customers or users) then you can use this business layer base class in other projects too. any thoughts?? Martin
life is a bowl of cherries go on take a byte
-
Hello, >>1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance.<< How else are you going to do it?? If you embed data access code within the GUI presentation code, then when you make an ASP.Net version of that nifty windows forms app, you have to copy the code and maintain it in 2 places. What if you change the database underneath or even keep the database but access it through a web service (scaling it up)? What if you need data from both an SQL Database and aan XML file? I think its better to have a database layer , a business layer and a presentation layer. The business layer lets you fiddle with the incomming data before delivering a consistant picture the presentaion layer. if you have this layer then the presenation layer can only get either a modified dataset or a strongly type class with field names specified.(How else??) (In fact all the presentaion layer may do is bind the gui controls to the business layer classes) I think this gives you the best longterm maintenance/development mix , which is surely worth a little extra pain at the begining. And dont forget the code reuse possibilities at the database layer . It could receive a command in "standard" Query and convert it to the correct format needed by whatever database/file/whatever is needed. New format means adding a class to the database layer - Once! Indeed if you have a standarad business layer class and then derive individual classes for the data entities (ie employees or customers or users) then you can use this business layer base class in other projects too. any thoughts?? Martin
life is a bowl of cherries go on take a byte
MartyK2007 wrote:
How else are you going to do it??
The old fashioned way. BindingSource and DataTable. 90% of the time I don't need to access the fields in a row directly--I just let the binding mechanisms handle that.
MartyK2007 wrote:
What if you change the database underneath
The database or schema? In either case, I'm using views (not SQL views, but programatically constructed views) of the schema, and the engine that's doing that is abstracted enough that I can implement other DB platforms as well?
MartyK2007 wrote:
or even keep the database but access it through a web service (scaling it up)?
Well, the point of an n-tier architecture is that the middleware can serve the data to the client from a variety of sources--a DB, a web service, an XML file, whatever. And that's what Interacx is, a middleware application.
MartyK2007 wrote:
I think its better to have a database layer , a business layer and a presentation layer.
Agreed. But where do those live? I find there's a lot of flexibility and ease of maintenance to move the BL and DL to the middleware component, leaving the client to be just the PL. Now of course you'd also want the flexibility to implement client-side BL, but the DL still lives in the middleware component.
MartyK2007 wrote:
if you have this layer then the presenation layer can only get either a modified dataset or a strongly type class with field names specified.(How else??)
Correct. With data binding, you don't need a strongly typed class. You can work with the DataTable/DataSet directly. Yes, there is a mapping of the field names to the controls. In my architecture (and stuff I've been doing for more than 10 years now) that mapping is automated in the sense that 1) it uses view fields so I can decouple the physical table field name and 2) I do the mapping declaratively in the form definition (an XML file) so A) it's easy to maintain on the server and B) I'm not recompiling code if I do want to change the mapping.
MartyK2007 wrote:
I think this gives you the best longterm maintenance/development mix , which is surely worth a little extra pain at the begining.
Well, that's why I wrote Interacx. Because besid
-
MartyK2007 wrote:
How else are you going to do it??
The old fashioned way. BindingSource and DataTable. 90% of the time I don't need to access the fields in a row directly--I just let the binding mechanisms handle that.
MartyK2007 wrote:
What if you change the database underneath
The database or schema? In either case, I'm using views (not SQL views, but programatically constructed views) of the schema, and the engine that's doing that is abstracted enough that I can implement other DB platforms as well?
MartyK2007 wrote:
or even keep the database but access it through a web service (scaling it up)?
Well, the point of an n-tier architecture is that the middleware can serve the data to the client from a variety of sources--a DB, a web service, an XML file, whatever. And that's what Interacx is, a middleware application.
MartyK2007 wrote:
I think its better to have a database layer , a business layer and a presentation layer.
Agreed. But where do those live? I find there's a lot of flexibility and ease of maintenance to move the BL and DL to the middleware component, leaving the client to be just the PL. Now of course you'd also want the flexibility to implement client-side BL, but the DL still lives in the middleware component.
MartyK2007 wrote:
if you have this layer then the presenation layer can only get either a modified dataset or a strongly type class with field names specified.(How else??)
Correct. With data binding, you don't need a strongly typed class. You can work with the DataTable/DataSet directly. Yes, there is a mapping of the field names to the controls. In my architecture (and stuff I've been doing for more than 10 years now) that mapping is automated in the sense that 1) it uses view fields so I can decouple the physical table field name and 2) I do the mapping declaratively in the form definition (an XML file) so A) it's easy to maintain on the server and B) I'm not recompiling code if I do want to change the mapping.
MartyK2007 wrote:
I think this gives you the best longterm maintenance/development mix , which is surely worth a little extra pain at the begining.
Well, that's why I wrote Interacx. Because besid
hey just took a look at your interacx site very interesting! I am just starting to head in your direction with my stuff and you've already done it! sigh! (just about finished writing a fairly generic data access layer using passed datasets) When do you intend to have the documenatation microsite up and running?? have you considered a single developers license?(as in a Cheap version ) Then when they sell their own stuff they wrote the company buying would have to get your corporate product. It means you could have a lot more products written using your structure/software and that could mean more corporate sales?? thanks Martin
life is a bowl of cherries go on take a byte
-
I'm reading a bit on LINQ; it seems very interesting - I almost get the feeling that this could be a very big thing. Even though I wouldn't go so far, some people out there even think that it may toss the good old database best practices out of the window: stuff like "if the backend can, the backend SHALL", stored procedures etc., so basically treating the database as a loose shcema bit bucket. How do you fell about this? Is something "big" underway? Sometimes old practices die and new ones emerge although I love the stability/flexibility of stored procedures.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandLINQ is just another "layer of abstraction" over something we already know how to work with whther it be XML or databases. As a result it will be inefficient since it sits on top of other APIs. What's more it is a "redundant" solution to things that have alraedy been solved. I have read through one of the early manuals on LINQ and though it appears to be nicely put together it means learning a new methodology of accessing data which appears rather arcane while not really providing any real benefit other than you will be able to read different types of data with SQL-like statements. However, XML-LINQ on the other hand may make XML access somewhat less arcane and thus easier to work with. So far, mots of the offerings by Microsoft recently are in fact redundant solutions to problems that have already been solved...
Steve Naidamast Black Falcon Software, Inc. blackfalconsoftware@ix.netcom.com
-
hey just took a look at your interacx site very interesting! I am just starting to head in your direction with my stuff and you've already done it! sigh! (just about finished writing a fairly generic data access layer using passed datasets) When do you intend to have the documenatation microsite up and running?? have you considered a single developers license?(as in a Cheap version ) Then when they sell their own stuff they wrote the company buying would have to get your corporate product. It means you could have a lot more products written using your structure/software and that could mean more corporate sales?? thanks Martin
life is a bowl of cherries go on take a byte
MartyK2007 wrote:
When do you intend to have the documenatation microsite up and running??
I'm working on the documentation. I've got the intro and Ch 1 & 2 written. If you want, send me a direct email and I'll send you the docs so far.
MartyK2007 wrote:
have you considered a single developers license?(as in a Cheap version )
Ah, that's a good idea! Marc
-
DLinq is a big mess[^] What's wrong with DLinq? Here's the list I have so far: attribute-based, MS Sql Server only, overly complicated, poor stored proc support, no server-side paging, very limited functionality, and no WinFS/OPath integration. I've commented on why attributes are superior to attributes before, and others are already chiming in on this, so I'm simply going to point out that they've failed in delivering their own goal to be "non-intrusive", which is stated in the DLinq docs. Next, while many people don't care about being able to simultaneously targetting multiple databases, its also very true that many people that target only one database do NOT work with MS Sql Server! DLinq is needlessly complex because it actually expects you to know a lot more than just ADO.NET and Sql, much like XLinq expects too much Xml knowledge. Consider their example query "from c in db.Customers where c.City == 'London' select c;" -- note that db.Customers only works because they have elsewhere defined Customers as a Table type. But you've already marked your Customer class with the attribute "Table(Name = 'Customers')", not too mention all the Column attributes -- so why isn't the attribute enough to make it clear what "Customers" refers to? etc. I'm beginning to sound like a broken record, but: 1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance. 2. I fundamentally disagree with entangling the schema with the UI presentation via tables. That's what views (and why they are called views) are for. They allow me to modify the schema without rewriting the visualization code. 3. I fundamentally disagree with interactions in application code that entangles non-abstracted (table again rather than view) schema with application-specific code. Again, change the schema, change the code. It creates brittle applications. 4. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code. 5. I'm not a fan of stored procedures, so for me, that's not an acceptable alternative. The only possible place that DLinq makes sense is in business rules, and then it still only makes sense of you'
What was wrong with facading the database and just using LINQ as a handy technology? Nobody is saying you *have* to pollute your business logic layer with schema produced classes. You just have to make sure that you don't couple the database in a logic layer which could possibly be ported to other apps later. Its all about managing expectations / assumptions / dependencies. Good Luck :)
-
What was wrong with facading the database and just using LINQ as a handy technology? Nobody is saying you *have* to pollute your business logic layer with schema produced classes. You just have to make sure that you don't couple the database in a logic layer which could possibly be ported to other apps later. Its all about managing expectations / assumptions / dependencies. Good Luck :)
The_Josher wrote:
What was wrong with facading the database and just using LINQ as a handy technology?
True, however, it doesn't look very compatible with the architecture I'm using. Sure, it'd be useful for thick 2-tier client development, but that's about it, IMO.
The_Josher wrote:
Its all about managing expectations / assumptions / dependencies.
Indeed. My expectations are very high, my assumptions is that the Microsoft way is the wrong way, and I hate being dependent on any technology that I didn't write myself. I guess I'm what you'd call a hard sell. Marc
-
I think it will be useful under certain circumstances (ie. high degree of customisation, small data sets) - but is unlikely to replace SQL and VFP in my frameworks, both are fast and tune-able. However is going to be a useful alternative to ado.net, which always causes me hassles :)
reshi999 wrote:
I think it will be useful under certain circumstances (ie. high degree of customisation, small data sets) - but is unlikely to replace SQL and VFP in my frameworks, both are fast and tune-able.
Whats VFP dude? I might be missing something that could simplify my life.
-
reshi999 wrote:
I think it will be useful under certain circumstances (ie. high degree of customisation, small data sets) - but is unlikely to replace SQL and VFP in my frameworks, both are fast and tune-able.
Whats VFP dude? I might be missing something that could simplify my life.
Ah sorry, VFP = Visual Foxpro - it is one of microsofts database languages which aimed for the middle ground, solid database + average interface functionality. It can be incredibly fast at crunching data as its hard coded for it, so much so that it couldn't be integrated into the dotnet framework without drastically losing performance. The functionality of LINQ is similar to some of what I can do in VFP (ie native SQL calls, local processing, etc) and so had been nicknamed VFP.NET in some circles... But Microsoft are ditching VFP in favour of dotNet, 1 more official version will be released and then it becomes an open source project - This is something to look forward to as it is a solid language with lots of potential (in my humble opinion). Anyway I have coded a distributed system with c# front end, SQL database and VFP processing in grid like fashion - is nice and fast so I am happy.
-
Rocky Moore wrote:
You either use SQL or Sprocs, what is the option here?
I post the transactions up to the middleware server. As the transactions are processed, server-side business rules can be triggered on the field and row changes (like SQL triggers, but running in .NET not in the server, albeit possibly becoming moot given the .NET support in SQL 2005). The middleware server then dynamically generates the appropriate SQL and updates the DB.
Rocky Moore wrote:
but the one that really got me thinking was the "Inheritance" video using discriminators
Thanks! I'll watch it in a bit.
Rocky Moore wrote:
I know, the short time I have worked with Linq 2 Sql, it is really cleaning up my data layer and making it much more flexible in pulling in data and there are more features on the way.
You should write an article on "before" and "after". Marc
I knew there had to be database access somewhere ;) I guess in a situation such as that, generating your own dynamic SQL, you do not have any "need" for access tools as you have built you own, but for almost everyone else who has not built a custom solution, Linq 2 SQL can provide a good tool for access to data with little work. It too generates dynamic SQL (if you are not using sprocs) based on the syntax you use. Thought it was interesting though, that I can call a function in SQL on the server straight from my datacontext without even having to have it in a query.. Actually, there is a lot of information already on Linq and how it can help you build your data layer, not a real fan of rebuilding the wheel :)
Rocky <>< Latest Code Blog Post: Linq - One-to-One issues? Latest Tech Blog Post: ESnailer... Send postal mail for free!
-
How do you connect an array and an XML document to a stored proc, without running the stored proc first, then filtering the full result, in memory ?
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
DLinq is a big mess[^] What's wrong with DLinq? Here's the list I have so far: attribute-based, MS Sql Server only, overly complicated, poor stored proc support, no server-side paging, very limited functionality, and no WinFS/OPath integration. I've commented on why attributes are superior to attributes before, and others are already chiming in on this, so I'm simply going to point out that they've failed in delivering their own goal to be "non-intrusive", which is stated in the DLinq docs. Next, while many people don't care about being able to simultaneously targetting multiple databases, its also very true that many people that target only one database do NOT work with MS Sql Server! DLinq is needlessly complex because it actually expects you to know a lot more than just ADO.NET and Sql, much like XLinq expects too much Xml knowledge. Consider their example query "from c in db.Customers where c.City == 'London' select c;" -- note that db.Customers only works because they have elsewhere defined Customers as a Table type. But you've already marked your Customer class with the attribute "Table(Name = 'Customers')", not too mention all the Column attributes -- so why isn't the attribute enough to make it clear what "Customers" refers to? etc. I'm beginning to sound like a broken record, but: 1. I fundamentally disagree with creating classes to mirror the database schema, especially when the sole requirement is to move the data from a view to a UI and back again. Why? Unecessary duplication and maintenance. 2. I fundamentally disagree with entangling the schema with the UI presentation via tables. That's what views (and why they are called views) are for. They allow me to modify the schema without rewriting the visualization code. 3. I fundamentally disagree with interactions in application code that entangles non-abstracted (table again rather than view) schema with application-specific code. Again, change the schema, change the code. It creates brittle applications. 4. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code. 5. I'm not a fan of stored procedures, so for me, that's not an acceptable alternative. The only possible place that DLinq makes sense is in business rules, and then it still only makes sense of you'
Marc Clifton wrote:
I'm beginning to sound like a broken record, but:
No, you are exactly on the mark, and your points are exactly right. I make it a practice of building database table schema info into a 'metadata' table when a database is changed (using oledb or sql client to retrieve the table info) then I use this table in the app (now accessible also by odbc) to generate sql statements and data relationships. The result is if the database changes then the app framework (mostly) automatically adapts to the changes without app rebuilding. I always use Select * ... and design the tables to make this relatively efficient. Again if tables change the Select * ... automatically adapts. I use view tables to define columns and properties for grids etc so grid views can change without app change. For simplicity I use a codes database for all manner of code translations, things like transaction types, freight charges, branch codes, etc. I have a single maintenance user control which automatically builds on the fly the appropriate text boxes, combo boxes, check boxes required for the particular codes table maintenance, and automatically on the fly manages data create, modify and update and generates all appropriate sql statements. The approach seems to be in the opposite direction to MS and especially DLinq where code represents more and more specific instances of data and relies heavily on the structure of the underlying database. I was taught that OO best practice was to make code less reliant on the external environment not more reliant. I think that DLinq will create a great future for maintenance programmers.
-
Ok., I see your point :) I, on the other hand, like SQL programming. I do agree on the nastiness on writing proecdural querying code. Just feels unnatural.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandI've always been a believer in "one way to do something", with the only exception being when a better way comes along. But personally, SQL and C# do not mix. I come from a C/C++ background so C# was a natural transition. But SQL is bloody strange to me with all of its... WORDS. It almost looks like Visual Basic or something! :laugh: And of course the lack of intellisense and compile-time support is perhaps the worst part. But seriously, I agree that LINQ really looks wonderful and I can't wait to learn its ins-and-outs when I have the time, or when a good book comes out on the subject. Speaking of which, if anyone discovers a really great LINQ book, please post to the Project!
-
I hate writing and using and especially debugging stored procedures, i hate convoluted SQL performing calculations that would have been trivial to do in procedural code, and i really hate writing procedural code to perform queries. It's as if DLINQ was designed to make me happy... so yeah, i'm still waiting for the other shoe to drop. ;)
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
Does anybody agree with me that SQL from procedural code would be a lot easier if SQL were exposed as relational algebra rather than it's own vaguely English-like syntax? Query.Table.Add(tblOrderDetail); Query.Join.Add(tblOrder.ID,tblOrderDetail.Order) ... would make building server-side queries on the client programmatically a lot easier than now, when you have to write code to figure out where to put the commas and stuff like that. Does the SQL language actually make life easier for anyone who really works with relational databases, or does it just make it easier for people to play with Microsoft Access (and even then people just use the query builder)?