LINQ and the future of database design/programming
-
Nice post!
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.
But isn't that sometimes the logical design? What's the alternative? Sometimes the shoe fits and your BOL needs to move the data to the DAL.
Marc Clifton wrote:
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.
Agreed,
Marc Clifton wrote:
I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code.
That's why stored procedures are beautiful :):)
"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 RandRohde wrote:
But isn't that sometimes the logical design?
Logical only for the moment. I guess I come from a bizarre background where 1) I'm developing frameworks to handle unknown customer applications and 2) the requirements change quite a bit as use cases are explored, since nobody has done this sort of stuff before and we really don't know about usability until we watch people using the applications. And changes in usability changes the information we want to manage which changes the schema which changes the UI. Thank goodness I don't have to change the code or the SQL! Like I said, it makes sense at the business rule level, but again using views not tables. Marc
-
Christian Graus wrote:
but I fear that it's greatest use ( linking together disparate data sources ), will often be used in ways that turn out to be very costly.
How so?
"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 RandHow 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 )
-
martin_hughes wrote:
i'm very intrigued by it as I'm lazy, and hate writing tedious data access code.
Take a close look at it. I went to a presentation on it a couple months ago and was moderately impressed. There were still some questions that could not be answered because it's still in development. My primary concerns though involve features that I put a lot of thought into for my Interacx system, and which I have written several articles about here (data transaction logging). My architecture supports smart client (disconnected) mode, business rules triggered on field and record transactions, sandboxing and undo/redo capability. Before I consider Entity Framework, I want to see those things in action. Marc
I think my needs (or wants) will probably be less exacting than yours, in that I don't really have the skills, expertise, knowledge or know-how (and probably imagination!) to roll something like your Interacx architecture (looks like a fascinating couple of articles, btw, I will delve deep when time permits). In a sense, I guess I'm more of a "business" programmer in that the reason I write code is to solve business problems in my sphere of influence (I'm a glorified stores manager :) ), and what I need from development tools is the path of least effort/time - so if I can just point a tool at a database and say "go do this bit for me" then I'm more than happy, and probably won't question the why's and wherefore's that better equiped folk will. I do find software architecture a fascinating subject though :) I do find it odd, however, that although objects in programming are rapidly becoming the norm, database have stuck with the relational model through and through and that most developers seem to accept this situation and invest huge amounts of time and resource into bridging the gap. Surely (and I know there are some out there) object databases should become the norm?
-
Day off...pfft. Everybody knows our days off are spent slaving over Javascript. ;P Actually...now that I'm jobless, I have every day off! :-D
David Stone wrote:
Actually...now that I'm jobless, I have every day off!
Yeah, what's the story there? I thought students were supposed to go jobless in the fall, not summer...
----
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
-
I think my needs (or wants) will probably be less exacting than yours, in that I don't really have the skills, expertise, knowledge or know-how (and probably imagination!) to roll something like your Interacx architecture (looks like a fascinating couple of articles, btw, I will delve deep when time permits). In a sense, I guess I'm more of a "business" programmer in that the reason I write code is to solve business problems in my sphere of influence (I'm a glorified stores manager :) ), and what I need from development tools is the path of least effort/time - so if I can just point a tool at a database and say "go do this bit for me" then I'm more than happy, and probably won't question the why's and wherefore's that better equiped folk will. I do find software architecture a fascinating subject though :) I do find it odd, however, that although objects in programming are rapidly becoming the norm, database have stuck with the relational model through and through and that most developers seem to accept this situation and invest huge amounts of time and resource into bridging the gap. Surely (and I know there are some out there) object databases should become the norm?
martin_hughes wrote:
and what I need from development tools is the path of least effort/time
That definitely makes sense. :) I'm not advocating one solution fits all, but in my corner of the world, I've discovered I need solutions capable of handling dynamic requirements. Ah, I've been wishing lately for a straight forward project. Something that doesn't involve dealing with the quartz.dll and thread-processor affinity problems, or the CoreAVC codec and how the API call to the mediaController.Stop method hangs. Or a miriad of other problems dealing with USB, DVD's, networks, etc. Where's my Commodore 64!?!?!?
martin_hughes wrote:
Surely (and I know there are some out there) object databases should become the norm?
I think there's something to be said for a database optimized for data access and/or storage rather than optimized for the convenience of the programmer. :) Marc
-
martin_hughes wrote:
and what I need from development tools is the path of least effort/time
That definitely makes sense. :) I'm not advocating one solution fits all, but in my corner of the world, I've discovered I need solutions capable of handling dynamic requirements. Ah, I've been wishing lately for a straight forward project. Something that doesn't involve dealing with the quartz.dll and thread-processor affinity problems, or the CoreAVC codec and how the API call to the mediaController.Stop method hangs. Or a miriad of other problems dealing with USB, DVD's, networks, etc. Where's my Commodore 64!?!?!?
martin_hughes wrote:
Surely (and I know there are some out there) object databases should become the norm?
I think there's something to be said for a database optimized for data access and/or storage rather than optimized for the convenience of the programmer. :) Marc
Marc Clifton wrote:
Where's my Commodore 64!?!?!?
Probably in the same place as mine - the loft :)
Marc Clifton wrote:
Something that doesn't involve dealing with the quartz.dll and thread-processor affinity problems, or the CoreAVC codec and how the API call to the mediaController.Stop method hangs. Or a miriad of other problems dealing with USB, DVD's, networks, etc.
[schoom!] (Which is, of course, the internationally recognised sound of something passing over one's head at high velocity) I'm sure once quantum computing becomes the norm, and they can all simultaneously and spontaneously calculate God's phone number, our troubles will be behind us :)
-
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 RandI never have understood why programmers dislike relational SQL databases so much. The age of fine-tuned, fast performing, tightly coded applications is rapidly ending (actually it ended a couple years ago). The practice of programming software is being dumbed down more and more because "we can take advantage of advances in computing power/performance". If I believe everything coming from MS, I would believe that businesses want to hire sub-par programmers who can't possibly deal with "low level details" like DB access. The MS message with .NET started out as a wonderful new platform for creating web applications and has grown into something that I'm less and less impressed with. The fundamental problem of storing data in a way that satisfies the needs of an application, the needs of reporting tools/systems, the need of end-users has not changed or been improved in any significant way. Instead, we seem to be trying to hide the hard facts with layers of code that slow things down, move programmers farther and farther away from solving fundamental problems and treats software development as a much simpler act than it really is. I guess the underlying belief is that the fundamental problem presented by relational databases will resolved soon and the capability to benefit from that fundamental change will already be in place. The practical impact of LINQ may well be the creation of more work for DB professionals, not less. The types of databases programmers create, particularly inexperienced programmers, are usually very poor designs that do not lend themselves to robustness in-terms of access requirements. They may work for the application developer, but custom reports and queries will likely be overly complicated and difficult to perform. Programmers will likely feel they can skimp on the DB design because the code is going to deal with things for them. For my personal uses at my current employer, the practical benefits of LINQ are fairly limited. The system we use is very dynamic and very few table names or structures are actually static. There are core system tables that provide key definitions, but much of the actual data storage that is needed for applications, reports, end-user queies is created on-demand based on the nature of the project being worked on. LINQ could be used, but I feel it would take much more code, not less. In the areas where tables names and structures are static, LINQ could be useful, but 1) I tyically don't like to build classes around DB schemas, 2) I don't like to have
-
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 quoted:
I've commented on why attributes are superior to attributes before
Typo? Or just a really unfortunate case of clashing nomenclature? ;P
Marc Clifton wrote:
I fundamentally disagree with creating classes to mirror the database schema
Isn't there a potentially fundamental difference in requirements here, between the code that builds the database and the code that queries the database? Or even between querying for the purpose of editing and the purpose of reporting?
----
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
-
Marc Clifton quoted:
I've commented on why attributes are superior to attributes before
Typo? Or just a really unfortunate case of clashing nomenclature? ;P
Marc Clifton wrote:
I fundamentally disagree with creating classes to mirror the database schema
Isn't there a potentially fundamental difference in requirements here, between the code that builds the database and the code that queries the database? Or even between querying for the purpose of editing and the purpose of reporting?
----
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
Shog9 wrote:
Or even between querying for the purpose of editing and the purpose of reporting?
Yes, that's a good way of putting it. 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'
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. 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.
Excellent points, Marc.
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
-
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:
4. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code.
Just caught this - wtf? SQL statements are code - not procedural code, but code. How far does the separation between the statement of what's needed and the definition of what needs it need to be for you...? ;P
----
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
-
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 agree a lot with a lot of what you say (fundamentally), although probably for very different reasons. The way we present information to the user in the UI should never be thought of as having anything necessarily to do with the 'shape' of that information when it gets stored in the database (or other form of data storage), and yet it almost always does. This is very bad. The 'shape' of information in the data storage is to facilitate processing. The 'presentation' of information to the user is to facilitate their use (interaction) with that information. Two very different purposes, why do we keep on insisting on trying to make them the same?
-
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 )
Christian Graus wrote:
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 ?
Fantastic example... 5.
------------------------------------------- Damian - Insert snappy one-liner here.
-
I agree a lot with a lot of what you say (fundamentally), although probably for very different reasons. The way we present information to the user in the UI should never be thought of as having anything necessarily to do with the 'shape' of that information when it gets stored in the database (or other form of data storage), and yet it almost always does. This is very bad. The 'shape' of information in the data storage is to facilitate processing. The 'presentation' of information to the user is to facilitate their use (interaction) with that information. Two very different purposes, why do we keep on insisting on trying to make them the same?
Lee Humphries wrote:
Two very different purposes, why do we keep on insisting on trying to make them the same?
Exactly. This "impedence mismatch" phrase that's used to describe this problem assumes that it IS a problem! I never have seen it as a problem--to me, it's the right way. Marc
-
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 Rand -
Nice post!
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.
But isn't that sometimes the logical design? What's the alternative? Sometimes the shoe fits and your BOL needs to move the data to the DAL.
Marc Clifton wrote:
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.
Agreed,
Marc Clifton wrote:
I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code.
That's why stored procedures are beautiful :):)
"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 RandAgree on all. Wher is the long awaited object database that could fit natrurally with object language Concerning Linq, usage seem to be inside sql server to write easy strored proc in another language, you make your assembly in C# or anything else (VeBe) and use linq to address data work. FoxPro was just a client(-server) tool, is it this 'rich (heavy) client XXV' story ? CS
-
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
Unfortunately, it was designed to solve a problem, not to make you happy.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
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 RandI 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 :)
-
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 Rand -
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'
Sometimes I want arrays-of-fixed-size-records back. Those were the days :( There is no persistance mechanism that allows me to adequately persist an in-memory data structure. Most mechanisms require some intermediate data structure unless you directly work on the disk data, or design the in-memory structure to cooperate with the particular serialization mechanism you have in mind. I fundamentally disagree with harcoding SQL statements (and that extends to DLinq) in code. It's the only point where I disagree (albeit not fundamentally so). Fair is, they need to be isolated since they are a migration and maintenance risk. Using views instead of tables, you already have the flexibility to shield applications from schema changes in the database, so the queries should be reasonable resistant to change. Or are you thinking of a problem I am missing? I was hoping that Linq, DLinq and XLinq bring "single file storage" and "database storage" closer together, allowing (with some forethought) to isolate migration to specific parts. We aren#t there yet, it seems.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist