I read this article with big respect to author. His own mind is more interesting for me, because the problem of developing database applications where we can create scalable application and have easy and flexible way for retrieving data from databases is very difficult for everyone who develope that applications. Indeed, when we create the library with methods of retrieving data from database we create big dependency of our programm product from wishes our clients, we need update recompilied libraries by system of upgrading(it is not so cheap). If we create dynamical structure of database where clients can easily modificate the procedures and parameters of query to data we have problem with reliability of database and their testing for all situations that can be possible in future usage.
So attempt to start creating code on high level of programming by ready-to-use methods that very similar with sql language is it new attempt to find middle way between dynamical heavy creating of structure of database and simple creation of libraries where we will need to trace the number of version of assembling.
It is hard to predict will it or not it has the success in future for big projects where security for access is on the first place, but for small task in office programming it is very suitable. Because it is so easy way to learn the sql language and use it for simple office's task.
Sincerely, LukCAD
Discussion on:
View:
Show:
A provider is a software module that provides a uniform interface between a service and a data source. Providers abstract physical storage media, in much the same way that device drivers abstract physical hardware devices. Because virtually all ASP.NET 2.0 state-management services are provider-based, storing session state or membership state in an Oracle database rather than a Microsoft SQL Server database is as simple as plugging in Oracle session state and membership providers. Code outside the provider layer needn't be modified, and a simple configuration change, accomplished declaratively through Web.config, connects the relevant services to the Oracle providers.
Thanks to the provider model, ASP.NET 2.0 can be configured to store state virtually anywhere. Membership data, for example, could just as easily come from a Web service as from a database. All that's required is a custom provider. Some companies will prefer to acquire custom providers from third parties. Others, however, will want to write their own, either because no suitable provider is available off the shelf, or because they wish to adapt ASP.NET to legacy storage media (for example, existing membership databases). This whitepaper documents the ASP.NET 2.0 provider model and provides the critical information that developers need to write robust, high-quality providers.
Just look at the http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/ASPNETProvMod_Intro.asp
Thanks to the provider model, ASP.NET 2.0 can be configured to store state virtually anywhere. Membership data, for example, could just as easily come from a Web service as from a database. All that's required is a custom provider. Some companies will prefer to acquire custom providers from third parties. Others, however, will want to write their own, either because no suitable provider is available off the shelf, or because they wish to adapt ASP.NET to legacy storage media (for example, existing membership databases). This whitepaper documents the ASP.NET 2.0 provider model and provides the critical information that developers need to write robust, high-quality providers.
Just look at the http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/ASPNETProvMod_Intro.asp
As a developer in the .Net and Java worlds, it seems to me that the more I learn about LINQ, the more I liken it to Hibernate (basically incorporating a database and all it entails into data objects and querying the data objects themselves).
It might be worthwhile to find out how DBA's have began working with Hibernate and learn from their trials and tribulations.
It might be worthwhile to find out how DBA's have began working with Hibernate and learn from their trials and tribulations.
I like the quote "Whatever the back end can do, the back end should do" and I will keep that for future use. I might make it stronger by replacing ?should do? with ?will do" just because I prefer not using the word 'should'.
I say 'down with RAD' due to my experience with database logic being integrated with the front end or GUI. Most rapid application development methods seemingly encourage everything to be put on the front end (i.e. VB6). I agree with the author in that certain applications I?m willing to compromise, however this has often led to later headaches.
A major aspect of any SDLC that often seems under emphasized is maintenance. In this example it is MUCH easier to modify a SQL statement in the backend that is used commonly throughout than to correct every N occurrence within the front end. Simple applications will start with only one occurrence of database logic, however how many times have these applications grown out of control from any reasonable means of maintenance?!
From my experience, incorporating proper layers from the get go brings costs down 10 fold later on. I believe most would agree that the cost of the initial application development equates to only 20% of total cost. The other 80% of total cost is due to maintenance of system changes and bug fixes over the life of the application.
Check out this article about architecting an N-Tier approach: http://www.15seconds.com/issue/011023.htm
I say 'down with RAD' due to my experience with database logic being integrated with the front end or GUI. Most rapid application development methods seemingly encourage everything to be put on the front end (i.e. VB6). I agree with the author in that certain applications I?m willing to compromise, however this has often led to later headaches.
A major aspect of any SDLC that often seems under emphasized is maintenance. In this example it is MUCH easier to modify a SQL statement in the backend that is used commonly throughout than to correct every N occurrence within the front end. Simple applications will start with only one occurrence of database logic, however how many times have these applications grown out of control from any reasonable means of maintenance?!
From my experience, incorporating proper layers from the get go brings costs down 10 fold later on. I believe most would agree that the cost of the initial application development equates to only 20% of total cost. The other 80% of total cost is due to maintenance of system changes and bug fixes over the life of the application.
Check out this article about architecting an N-Tier approach: http://www.15seconds.com/issue/011023.htm
Not advocating down with RAD as it has a very viable place in the business community.
I am not a big Microsoft fan, but if you sit back and take LINQ for what it offers the choice can be very tantalizing. The code snippet offered by the author was very clean and easy to understand. Readability is a huge plus in my book as I have seen some very hard to read code.
LINQ, it seems, offers developers another way to do the same thing as ADO, but with multiple data sources. Taking this into account, I don?t foresee the migration of logic from the back to the front end. What I see is simply another way to access that logic.
The concern I have with LINQ, besides being in infancy, is the logic is strictly tied to the Microsoft Windows Platform. Given the sheer number of UNIX and UNIX like OS? in existence, I would be hesitant to adopt this technology as you are limiting portability of any objects you create. Then again, if you make .NET apps, you have presently limited your options as-is.
In short, for the .NET developers, I see this as becoming a large plus in .NET app development.
I am not a big Microsoft fan, but if you sit back and take LINQ for what it offers the choice can be very tantalizing. The code snippet offered by the author was very clean and easy to understand. Readability is a huge plus in my book as I have seen some very hard to read code.
LINQ, it seems, offers developers another way to do the same thing as ADO, but with multiple data sources. Taking this into account, I don?t foresee the migration of logic from the back to the front end. What I see is simply another way to access that logic.
The concern I have with LINQ, besides being in infancy, is the logic is strictly tied to the Microsoft Windows Platform. Given the sheer number of UNIX and UNIX like OS? in existence, I would be hesitant to adopt this technology as you are limiting portability of any objects you create. Then again, if you make .NET apps, you have presently limited your options as-is.
In short, for the .NET developers, I see this as becoming a large plus in .NET app development.
While I agree that putting the work on the server is a great idea, my argument is that it puts the developers in the DB as opposed to front-end. I've done development and have worked with some good one's.
But I've worked with developers that I didn't trust with the front-end let alone being in the DB.
But I've worked with developers that I didn't trust with the front-end let alone being in the DB.
Mr. Fuller is absolutely correct in his position that the back-end should do everything the back-end CAN do. As a developer who is also a DBA I have seen some horrendous sql embedded in front-end apps that could have been much more efficiently accomplished in a well-designed stored procedure. I do not see LINQ solving this problem. As far as the 'see spot run' example presented in the article, the actual SQL code would not be more complex and would not vary significantly between a SQL Server and Oracle database (can't speak for DB2). Having said that, like Mr. Fuller, I can't get too excited about LINQ.
It seems to me that there's a big hang-up on "back-end should do everything the back-end CAN do" instead of talking about LINQ as a viable or non-viable technology.
The problem that LINQ addresses is middle tier data adaptation that is data source agnostic. The translation from DB tables to programmable constructs is one that plagues any software that has to interact with data, and the place where you have widely varying solutions, usually dynamically generated SQL/stored procs/packages populating some platform-specific flavor of an ADO-DataSet type construct. Given this problem, LINQ provides an attractive solution: conversion from data into strongly typed objects in the domain/data-access tier without losing the query-language flavor.
No doubt people like to reduce the amount of variables in their applications when they can, but broad statements like "the back-end should do everything the back-end CAN do" aren't always universally applicable. What isn't clear in the article is what the back end is. Is it the DB? The application server and DB? For some applications, the DB providers are just like the front end - that is, designed to be interchangeable based on the demands of the customer. Painting LINQ as a strictly mid-to-UI tier technology is a convenient sidestep of the fact that embedding large amounts of logic in the DB layer can be fairly expensive to create and maintain in it's own right. Anybody who's worked on converting an application (Oracle to SQL Server or vice versa) where much of the domain logic was located in the DB knows what a pain this can be. I agree with the author in this regard -- if you're in the situation where all of your non-UI related code is in the DB, LINQ isn't for you, and secondly, pray that you don't come across a client that demands a different data provider than the one you're currently in.
Returning to LINQ, in my mind, the jury is still out -- how LINQ will allow for optimized data access for the different data providers is the key. It's hard to throw away hard-won knowledge of how to optimize access for Oracle, SQL Server, XML, or any other data source out there. It's also hard to throw away the speed/load performance gains of such optimization for the sake of an easier time developing data access tiers. I for one, am hoping that LINQ does the trick. I'd rather have it as a viable development alternative than as a lame-duck technology waiting to get replaced.
The problem that LINQ addresses is middle tier data adaptation that is data source agnostic. The translation from DB tables to programmable constructs is one that plagues any software that has to interact with data, and the place where you have widely varying solutions, usually dynamically generated SQL/stored procs/packages populating some platform-specific flavor of an ADO-DataSet type construct. Given this problem, LINQ provides an attractive solution: conversion from data into strongly typed objects in the domain/data-access tier without losing the query-language flavor.
No doubt people like to reduce the amount of variables in their applications when they can, but broad statements like "the back-end should do everything the back-end CAN do" aren't always universally applicable. What isn't clear in the article is what the back end is. Is it the DB? The application server and DB? For some applications, the DB providers are just like the front end - that is, designed to be interchangeable based on the demands of the customer. Painting LINQ as a strictly mid-to-UI tier technology is a convenient sidestep of the fact that embedding large amounts of logic in the DB layer can be fairly expensive to create and maintain in it's own right. Anybody who's worked on converting an application (Oracle to SQL Server or vice versa) where much of the domain logic was located in the DB knows what a pain this can be. I agree with the author in this regard -- if you're in the situation where all of your non-UI related code is in the DB, LINQ isn't for you, and secondly, pray that you don't come across a client that demands a different data provider than the one you're currently in.
Returning to LINQ, in my mind, the jury is still out -- how LINQ will allow for optimized data access for the different data providers is the key. It's hard to throw away hard-won knowledge of how to optimize access for Oracle, SQL Server, XML, or any other data source out there. It's also hard to throw away the speed/load performance gains of such optimization for the sake of an easier time developing data access tiers. I for one, am hoping that LINQ does the trick. I'd rather have it as a viable development alternative than as a lame-duck technology waiting to get replaced.
Thanks mtan, that was exactly my feeling when I read Fuller's article.
In my view LINQ doesn't have so much to do with front end or back end. It appears to be a rather elegant way of replacing some awkward data access constructs.
But does it help us to elegantly bridge the gap between mostly relational databases and "programmable constructs" as mtan puts it. But for this LINQ seems to be just some helper technology and not the solution in itself.
In my view LINQ doesn't have so much to do with front end or back end. It appears to be a rather elegant way of replacing some awkward data access constructs.
But does it help us to elegantly bridge the gap between mostly relational databases and "programmable constructs" as mtan puts it. But for this LINQ seems to be just some helper technology and not the solution in itself.
Middleware.....
May be not for frontends. But for middleware this will be a big change in Application Servers and Integration Servers.
This could avoid writing adaptors for different database, and create one generic adaptor for all databases.
If LINQ is a generic language for all databases, why would it not be portable to multible databases ?
Cheers
Dennis
May be not for frontends. But for middleware this will be a big change in Application Servers and Integration Servers.
This could avoid writing adaptors for different database, and create one generic adaptor for all databases.
If LINQ is a generic language for all databases, why would it not be portable to multible databases ?
Cheers
Dennis
Just joshing you all.
Although I have always prefered to have the backend process all that it can, and leave the frontend just as that, a frontend, I was involved in the development of an administrative system for a services company (Water). We had many, many users generating many, many reports in the db, and I remember than certain querys generated recordsets so big, that the server became sluggish, killing performance to all the clients, what is something pretty bad if you work with people in a row who is waiting to pay.
I still think that the frontend should not do any processing job and definitely, no dynamic sql construction but I like the three-tier approach with careful considerations about performance and transaction load.
I still think that the frontend should not do any processing job and definitely, no dynamic sql construction but I like the three-tier approach with careful considerations about performance and transaction load.
There's no reason to assume that LINQ will only be a client-side construct.
With CLR now firmly inside SQL Server 2005, C# and VB can be used to write stored procedures. For instance, stored procedures that require a readonly forward cursor are substantially faster when written in a .NET language (as opposed to T-SQL).
LINQ would be great to write easier to read/easier to write .NET server-side stored procedures.
With CLR now firmly inside SQL Server 2005, C# and VB can be used to write stored procedures. For instance, stored procedures that require a readonly forward cursor are substantially faster when written in a .NET language (as opposed to T-SQL).
LINQ would be great to write easier to read/easier to write .NET server-side stored procedures.
LINQ is a tier neutral technology. On the front end one can use LINQ to query returned datasets, XML files etc and on the back end to query a database. IMHO the back end (data access tier - DAC) is the only tier that is allowed to access data storage like SQL Server. The front end can manipulate returned data from the back end but not retrieve or update it without using the DAC. LINQ is merely a uniform way of accessing different data sources. New functionality like LINQ does not force bad coding style, that is left up to the creativity of the developer.
The problem is that in 99% of examples, it's used to access a database table so it seems people have got a little hung up on that. But you are quite right, it's just another method to access data.
Was wondering about this technology for long time and got time today to watch some videos and read some articles.
I am with Arthur on putting logic as much as possible on the back end and have the front end as lean as possible. But some benefits i see with LINQ are the abilities to query file system, xml files, different data sources, build excel files etc. with few lines of codes.
I don't see this technology will replace the existing, traditional way of accessing data in near future. If i am calling a stored proc from my front end, what's the benefit of using LINQ in this. I use stored proc for all my projects, never had to construct a sql statement in the front end except in one case when i had to update .dbf files.
Nice article Arthur. You said same thing which came to my mind first when i learned about LINQ.
I am with Arthur on putting logic as much as possible on the back end and have the front end as lean as possible. But some benefits i see with LINQ are the abilities to query file system, xml files, different data sources, build excel files etc. with few lines of codes.
I don't see this technology will replace the existing, traditional way of accessing data in near future. If i am calling a stored proc from my front end, what's the benefit of using LINQ in this. I use stored proc for all my projects, never had to construct a sql statement in the front end except in one case when i had to update .dbf files.
Nice article Arthur. You said same thing which came to my mind first when i learned about LINQ.
how do you use PHP as aprogramming languauge?
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
