Anyone else using ADO.Net 2.0, stored procedures and wcf for databinding rather than using another framwork?
-
I know that LINQ, Entity Model and RIA Services (when it is available) are great and all, but I find that all the extrapolation makes me stupid and makes it harder to solve problems. I know it takes a few extra hours to write your own classes that represent your database objects, but I like the having the extra control. One of the things that kills me about ASP.Net MVC is that MS tells us one of the benefits is the granular control over the HTML. Well, I kind of like having the granular control over my database transactions. I also find that it is an important skill in the business world to be good at writing SQL. Being able to easily adhoc query your databases is also very important. I know it is a bit of extra work, but frankly I prefer to program that way. Anyone else agree with me?
I didn't get any requirements for the signature
-
I know that LINQ, Entity Model and RIA Services (when it is available) are great and all, but I find that all the extrapolation makes me stupid and makes it harder to solve problems. I know it takes a few extra hours to write your own classes that represent your database objects, but I like the having the extra control. One of the things that kills me about ASP.Net MVC is that MS tells us one of the benefits is the granular control over the HTML. Well, I kind of like having the granular control over my database transactions. I also find that it is an important skill in the business world to be good at writing SQL. Being able to easily adhoc query your databases is also very important. I know it is a bit of extra work, but frankly I prefer to program that way. Anyone else agree with me?
I didn't get any requirements for the signature
I still write my own data object classes, etc. For one thing, I have a lot of code and objects that were developed long before Linq, etc. that are still in use. Maybe I'm just missing something, but I don't see where Linq, etc. save me much work.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
I know that LINQ, Entity Model and RIA Services (when it is available) are great and all, but I find that all the extrapolation makes me stupid and makes it harder to solve problems. I know it takes a few extra hours to write your own classes that represent your database objects, but I like the having the extra control. One of the things that kills me about ASP.Net MVC is that MS tells us one of the benefits is the granular control over the HTML. Well, I kind of like having the granular control over my database transactions. I also find that it is an important skill in the business world to be good at writing SQL. Being able to easily adhoc query your databases is also very important. I know it is a bit of extra work, but frankly I prefer to program that way. Anyone else agree with me?
I didn't get any requirements for the signature
I always write my own SQL and I have found very little use for "entities" in my work and I can imagine few cases where they may be beneficial, so I expect that they are over-used (an anti-pattern). I was discussing this with a colleague the other day. The bottom line, to me, is the duration of the object -- will it last long enough to warrant spending time and effort creating it? And will it interact with other objects? If the answers to these questions are both "yes", then go right ahead and use an object. If not, why bother? Let's put it this way... if all you're doing is querying data and writing it to a file (a simple list of customers for instance) then I see no point in bothering with instantiating an object for each customer just to dispose it immediately. P.S. I don't do stored procedures, I don't do WCF, I don't do databinding.
-
I still write my own data object classes, etc. For one thing, I have a lot of code and objects that were developed long before Linq, etc. that are still in use. Maybe I'm just missing something, but I don't see where Linq, etc. save me much work.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
Walt Fair, Jr. wrote:
Maybe I'm just missing something, but I don't see where Linq, etc. save me much work.
Agreed.
I didn't get any requirements for the signature
-
I always write my own SQL and I have found very little use for "entities" in my work and I can imagine few cases where they may be beneficial, so I expect that they are over-used (an anti-pattern). I was discussing this with a colleague the other day. The bottom line, to me, is the duration of the object -- will it last long enough to warrant spending time and effort creating it? And will it interact with other objects? If the answers to these questions are both "yes", then go right ahead and use an object. If not, why bother? Let's put it this way... if all you're doing is querying data and writing it to a file (a simple list of customers for instance) then I see no point in bothering with instantiating an object for each customer just to dispose it immediately. P.S. I don't do stored procedures, I don't do WCF, I don't do databinding.
I agree with you. I do use stored procedures, but I don't really need to. I don't really like databinding either.
I didn't get any requirements for the signature