LINQ and the future of database design/programming
-
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 -
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