Linq to Salesforce "SQL" provider - c#

So, I have this new project. My company uses the SalesForce.com cloud to store information about day-to-day operations. My job is to write a new application that will, among other things, more seamlessly integrate the CRUD operations of this data with existing in-house application functionality.
The heart of the Salesforce WSDL API is a set of "query()" web methods that take the query command as a string. The syntax of the query is SQL-ish, but not quite (they call it SOQL). I'm not a fan of "magic strings", so I'd like to use Linq in the codebase, and parse the IQueryable into the SOQL query I need in the wrapper for the service. It's certainly possible (L2E, L2Sql), but I'd like to know if there's a shortcut, 'cause if I say it'll take more than a day or two to roll my own, I'll be "encouraged" to find another method (most likely a method for each general-use query, which was the method used in older apps). If I succeed in making a general-purpose SOQL parser, we can use it in several other upcoming apps, and I'll be a hero. Even if I make a simple one that only supports certain query structures, it'll go a long way by allowing me to proceed with the current project in a Linq-y way, and I can expand on it in my free time.
Here are the options as I see it:
Look harder for an existing Linq2SOQL provider (My Google-fu is failing me here, or else there simply isn't one; the only .NET wrapper only mentions Linq as a nice-to-have).
Build an expression tree parser. It needs to support, at least, the Select and Where method calls, and needs to either parse lambdas or manipulate their method bodies to get the operations and projections needed. This seems to be a rather massive task, but like I said, it's certainly possible.
Wrap the service in Linq2Sql or a similar existing Linq provider that will allow me to extract a close-enough query string, polish it up and pass it to the service. There must be dozens out there (though none that just drop in, AFAIK).
Call Expression.ToString() (or Expression.DebugView), and manipulate that string to create the SOQL query. It'll be brittle, it'll be ugly (behind the scenes), and it will support only what I'm explicitly looking for, but it will provide a rudimentary translation that will allow me to move on.
What do you guys think? Is building a Linq parser more than a two-day task for one guy? Would a bodged-up solution involving an existing Linq provider possibly do it? Would it be terrible to chop up the expression string and construct my query that way?
EDIT: Thanks to Kirk for the grounding. I took some more looks at what I'd be required to do for even a basic SOQL parser, and it's just beyond the scope of me getting working application code written on any feasible schedule. For instance, I have to build a select list from either the Select() method lambda or a default one from all known columns from my WSDL object, a task I hadn't even thought of (I was focusing more on the Where parsing). I'm sure there are many other "unknown unknowns" that could turn this into a pretty big deal. I found several links which shows the basics of writing a Linq provider, and though they all try to make it simple, it's just not going to be feasible time-wise right now. I'll structure my repository, for now, using named methods that encapsulate named queries (a constant class of formattable query strings should reduce the amount of head-scratching in maintenance). Not perfect, but far more feasible. If and when a Linq2SOQL provider gets off the ground, either in-house or open-source, we can refactor.
For others looking for Linq provider references, here are those helpful links I found:
Building a Linq Provider
Walkthrough: Creating an IQueryable LINQ Provider
Linq: Building an IQueryable provider series - in 17 parts! <-- this one, though long and involved, has a lot of real in-depth explanations and is good for "first-timers".

Let's take them one at a time:
Look harder for an existing Linq2SOQL provider (My Google-fu is failing me here, or else there simply isn't one; the only .NET wrapper only mentions Linq as a nice-to-have).
Yeah, I doubt one exists already, but hopefully you can find one.
Build an expression tree parser. It needs to support, at least, the Select and Where method calls, and needs to either parse lambdas or manipulate their method bodies to get the operations and projections needed. This seems to be a rather massive task, but like I said, it's certainly possible.
This is absolutely the way to go if you really are serious about this in the long-run.
Wrap the service in Linq2Sql or a similar existing Linq provider that will allow me to extract a close-enough query string, polish it up and pass it to the service. There must be dozens out there (though none that just drop in, AFAIK).
What do you mean by "drop in"? You can easily get the SQL straight from L2S.
Call Expression.ToString() (or Expression.DebugView), and manipulate that string to create the SOQL query. It'll be brittle, it'll be ugly (behind the scenes), and it will support only what I'm explicitly looking for, but it will provide a rudimentary translation that will allow me to move on.
I would strongly discourage you from this approach, as, at minimum, it will be at least as difficult as parsing the expression trees properly. If anything, in order to use this, you'd have to first put the parsed strings into a proper object model -- i.e. the existing expression trees you're starting with.
Really, you should think about building a query provider and doing this right. I think two days is a bit of a stretch though to get something working in even a primitive sense, though it might be possible. IMO, you should research it some at home and toy around with it so you have some familiarity with the basic pieces and parts. Then you might barely be able to get some usable queries going after two days.
Honestly though, fully implementing this kind of project is really in the realm of several weeks, if not months -- not days.
If that's too much work, you might consider option 3. I'm no expert on SOQL, so no idea what kind of work would be involved transforming ordinary SQL queries into SOQL queries. If you think it's rather algorithmic and reliable, that might be the way to go.

Related

Object Auditing

currently we have quite a chunky auditing system for objects within our application, the flow goes like this..
-Class implements an interface
-Interfaces forces the class to override some methods for adding properties that need auditing to a List of KeyValuePairs
-Class is then also needs to recreate the objects state from a list of key value pairs
Now the developer needs to add all this to there class, also our objects change quite often so we didn't just serialise the class.
What I would like to do is to use attributes to mark the properties as auditable and then do everything automatically so the developer doesn't really need to do anything.
My Main question is - I know people always say reflection is slow, how slow are we talking? what performance hits am I going to get from looking through the class and looking at attributes against a property and then doing any required logic?
thanks for any help
Ste,
It's hard to give a specific answer because it depends on what adequate performance is for your application.
Reflection is slower then normal compiled code but when worrying about performance problems it's always better to have something that works and then use profiling to find the real performance bottleneck and optimize.
Premature optimization could lead to code that's much harder to maintain so your developers will be less productive.
I would start with using reflection and write a good set of unit tests so you know your code is working. If performance turns out to be a problem you can use the Visual Studio profiler to profile your unit tests and discover the bottlenecks.
There are some libraries that can speed up reflection or you could use Expression trees to replace your reflection code if it's to slow.
If the performance ok or not depends on your app context. So it's difficult to say if it is slow or fast for you, you should try it by yourself.
Most probably, imo, it would give pretty acceptable performance, but again I have no idea where you gonna use it.
Like other solutions that come to my mind, could be:
Sqlite, where to save the key/value data
Aspect Oriented Programming (like a PostSharp) to generate a data in compile time.
But the first thing I would try, is a Reflection, just like you think.
Reading this response from Marc I would suggest that Reflection should be fine for most application needs.
Before making any fundamental changes I would suggest running a profiler to find the bottlenecks in your code. If you identify the reflection / auditing process is the major pain point use an IL Emit and try again.
Reflection is the way to go here. If it's too slow(measure!) you can throw in a bit of caching, or in the worst case generate an Expression<T> and compile it.
There are two phases in your problem:
Figure out which properties you want, and return a list of their PropertyInfos. You need to do this only once per type, and then you can cache it. Thus performance of this step doesn't matter.
Getting the value of each property with PropertyInfo.GetValue.
If this step 2 is too slow, you need to generate an Expression in step 1, and the overhead over manually written code goes down to a single delegate invocation.

Should I not use LINQ to objects because Microsoft might change it?

I got into an argument with a co-worker about the use of LINQ to Objects (IEnumerable, not IQueryable) in our C# code. I was using LINQ, and he said that we shouldn't be using an external vendor's (Microsoft) code in our code, but that we should wrap it ourselves in our own layer of abstraction.
Now I understand this methodology for use where you've got a no-name third party dll that may go out of business next week, or when your dealing with database calls (ie. returning a common data provider, rather than a SQL or Oracle specific one), but in my mind the LINQ syntax is too pretty/elegant/readable for Microsoft to abandon in the next 10 years. It's about as likely to be dropped as the ToString("Hello {0}", firstName); functionality.
I could give up arguing, and implement our own LINQ library that calls the standard LINQ methods under the covers, but isn't this over doing it? Plus I could only use the extension methods, I have no idea how to be able to wrap this:
from e in employees
select new { e.Name, e.Id };
What would your argument be, for or against using LINQ to objects (the IEnumerable extension methods)?
Your friend is wrong. LINQ was the flagship feature of C# 3.0, and will not be leaving the language. There's always a chance MS will cease to support C# (though I severely doubt that,) but as long as there's a C#, there will be LINQ.
Also, consider in which assembly the LINQ-to-objects extension methods are housed: System.Core.
He is completely wrong.
That argument only applies when dealing with fungible components, such as database platforms.
Microsoft is extremely careful to avoid making breaking changes in .Net; there is no way that they would drop LINQ.
To answer your other points, query comprehension syntax (from x in y) is a compiler feature which is transformed into method calls.
If you write your own methods, the compiler will happily use them.
There are already third party implementations of the LINQ to Objects methods, such as LINQBridge (for use with .Net 2.0, which predates LINQ), or EduLINQ (written for educational purposes)
I was using LINQ, and he said that we shouldn't be using an external vendor's (Microsoft) code in our code, but that we should wrap it ourselves in our own layer of abstraction.
It's a core part of the language (i.e., part of the C# language specification). It'll be around as long as C# is around. Changes to it would be breaking changes, and would be a massive cost to Microsoft's customers. They are not going to do this.
Wrapping a layer dependency like ADO.NET or a third-party library: idea worth considering.
Wrapping LINQ to Objects (core part of framework and game-changer): bad idea.
Maybe your co-worker simply feels that this is more correct:
var result = employees.Select(e => new { e.Name, e.Id });
Regardless, I think your co-worker's worries are completely unfounded.
...interesting...

Looking to design a tool to Translate Business logic from Stored Procedures to C# Business Layer [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
Without getting into a discussion about whether the business logic should be in the database or at the application layer, since it has been covered elsewhere.
My team is translating 100K+ lines of PL/SQL code and moving the logic from the database into the application. We were using VB6 with straight calls to Oracle 9i Stored Procedures and Ad-hoc queries and are now using C#, .net 3.5, Winforms with NHibernate to an Oracle 9i database.
We have already found a wonderful tool to assist in converting the Ad-hoc queries, SmartCode, but it only creates code based on Tables and Views. We are looking for a tool to assist in converting the Stored Procedures.
The Stored Procedures have most of the Business logic in them that we want to migrate to the application layer. We are wondering if there are any tools to convert the Stored Procedures into C# code.
Assuming there are none, what would be the best place to start if we develop the tool in-house/open source. Is there another similar system with similar goals that could be used as a starting place?
Accepted Answer UPDATE:
I have selected scope-creep's answer, because it appears to be the best method for implementing the issue presented in the question. For those that deal with this same issue, I heartedly recommend Adam's response, as he has strongly advocated against the use of a tool and provides a strong rationale. He has also provided the most interaction with this question and had the most up-voted response.
Thank you to everyone for your help and dialog.
I don't believe there are any converters for SQL to C#.
As for approaching the creation of such a tool, I would first say, don't... your business requirement sounds like it is to get the logic into C#.
Depending on the state of the application, you can do this in many ways: one sproc at a time; logical entities at a time (all customer logic, etc); whole hog; agile-ish where you leave the sprocs alone for the time being and call straight into them from C#, and then slowly take one of the prior approaches - always leaving yourself with a functioning application.
Loaded question really :-)
I personally would first try to get it working in C# straight calling into the sprocs. Then take logical entities, as you will find they may reference other sprocs. Doing a sproc at a time will fragment your C# logic during development and add extra overhead to the creation of business classes.
The strength in a C# domain model is the clear boundaries of responsibility and grouping of behaviour into your logical entities - so taking a sproc at a time, you will not see the bigger picture. Using a converter, it will end in unreadable, unmanageable code that you then have to learn - something you don't need to do if you created it in the first place.
So my conclusion, if there is one, is to save yourself time in the future and take this as an opportunity to redesign your business layer - as you likely have knowledge and experience of the system's production behaviour from out in the wild, so the conversion can factor in any lessons learnt.
Update: it turns out you have tooling options for the conversion. The only thing I will say to that approach is this: the resulting code is not going to be pretty. You have the benefit that your current SQL is understood by the development team - they know the code. A code generator is going to produce 100% new code that no one knows. Learning curve... as you are going to need to verify the output of the tool to make sure it isn't mutating your logic - no tool is infallible.
If you decide to use the tool, I can only suggest to break the conversion down into very, very small parts (presumably the smallest is going to be a script (or perhaps even batch within a script)). When you have a small set of conversion results, integrate this into the application and pass it through a review process.
One way to do it is to use ANTLR v3, to construct a domain specific language. ANTLR V3 has a PL/SQL Pl/SQL grammer for 10g,11g to construct a lexer/parser for PL/SQL, which would be the first step. A C# 3.0 code generator is available for the backend for C#3.0. The code generator is still under development, but it's in an advanced state.
I don't know how much work would ensue with this approach, but I certainly think it would cost less than doing manual translation.
There is a book available called The Definitive ANTLR Reference: Building Domain-Specific Languages . I know suggesting a book at this time, when you have a sh't load of work to do is crass, but it will give you an idea of the process involved, and perhaps enough to cost the conversion.
There has already been a question on Stack Overflow: Writing a Language Translator which links to the ANTLR Morph project, which is a subproject to define a common translation mechanism. The Doc and FAQ explain how it works. Essentially a script is used to define a translation mechanism. Its in early stages yet, but could be worth a look, as this is a common scenario which has not been addressed as yet.
This example explains how do create tree transformations, i.e. walking the tree to output translated code, found here: Tree Translations, with associated ANTLR documentation: Tree Consuruction
Finding the right compiler engineer would be key to success. I had a look at some sites, and their are a few compiler engineers available. I think it would be less expensive employing 1 or 2 compiler engineers for 3+ months, to do the work than employing than 4+ engineers for 3+ months for manual translation. In the UK you would be looking for a contractor to do it.
Hope that helps
Bob.
Edit: 01/08
I've found another book which discusses creating language translators, found here, called
Language Implementation Patterns
I couldn't find anything that converts PL/SQL directly to C#, but found a couple products that convert PL/SQL to Java (which you can then convert to C#).
Convert PL/SQL to Java:
SwisSQL: http://www.swissql.com/products/oracle-to-java/oracle-to-java.html
Exodus: http://www.ciphersoftinc.com/products/plsql-to-java-conversion-tools.html
Convert Java to C#
StackOverflow answer: Tool to convert java to c# code
Based on the input from scope-creep, Adam and Ira-Baxter. Especially, concerning doing things in a bite-sized fashion, clear boundaries of responsibility and grouping of behavior
One way would be to extend the SmartCode tool, which is already generating nice entities to work with and since it is open-source:
Extend the tool to read in the stored procedures, allowing for selection of stored procedures with reverse table/view selection (assuming there are any references in the stored procedures for tables/views not currently mapped).
Using the entities created by the tables and views, convert the packages, with containing stored procedures, to a class hierarchy.
Translate the business logic using lexicons and grammars.
Thoughts?
I hope this helps:
Generating a Stored Procedure Declarations for NHibernate in PL/SQL
Generating a Stored Procedure Wrapper for NHibernate in PL/SQL
If you're doing NHibernate with Oracle, you want to read Devio's blog.
LLBLGen Pro feature:
Building blocks for your code: Entities, Value Types, Typed Lists, Typed Views and Stored Procedure calls.

Delegates and Lambdas and LINQ, Oh My!

As a fairly junior developer, I'm running into a problem that highlights my lack of experience and the holes in my knowledge. Please excuse me if the preamble here is too long.
I find myself on a project that involves my needing to learn a number of new (to me) technologies, including LINQ (to OBJECTS and to XML for purposes of this project) among others. Everything I've read to this point suggests that to utilize LINQ I'll need to fully understand the following (Delegates, Anonymous Methods and Lambda Expressions).
OK, so now comes the fun. I've CONSUMED delegates in the past as I have worked with the .NET event model, but the majority of the details have been hidden from me (thanks Microsoft!). I understand that on a basic level, delegate instances are pointers to methods (a gross over-simplification, I know).
I understand that an anonymous method is essentially an in-line unnamed method generally (if not exclusively) created as a target for a delegate.
I also understand that lambdas are used in varying ways to simplfy syntax and can be used to point a simple anonymous method to a delegate.
Pardon me if my any of my descriptions are WAY off here, this is the basic level to which I understand these topics.
So, the challenge:
Can anyone tell me if at least on a basic level if my understanding of these items is even close? I'm not looking for complex esoteric minutiae, just the basics (for now).
To what degree do I need to truly understand these concepts before applying LINQ in a project to reasonable effect? I want to understand it fully and am willing to spend the time. I simply may not HAVE the time to fully grok all of this stuff before I need to produce some work.
Can anyone point me to some good articles that explain these subjects and apply them to "real world" examples so that I can get my head around the basics of the topics and application of them? What I mean by real world, is how might I use this in the context of "Customers and Invoices" rather than abstract "Vectors and Shapes" or "Animals and Cows". The scenario can be somewhat contrived for demonstration purposes, but hopefully not strictly academic. I have found a number of examples on-line and in books, but few seem to be "Plain English" explanations.
Thank you all in advance for your patience, time and expertise.
Where can i find a good in depth guide to C# 3?
1) Your knowledge so far seems ok. Lambda expressions are turned into anonymous methods or System.Linq.Expressions.Expression's, depending on context. Since you aren't using a database technology, you don't need to understand expressions (all lambdas will be anonymous methods). You didn't list Extension methods, but those are very important (and easy) to understand. Make sure you see how to apply an extension method to an interface - as all the functionality in linq comes from System.Linq.Enumerable - a collection of extention methods against IEnumerable(Of T).
2) You don't need a deep understanding of lambdas.
The arrow syntax ( => ) was the biggest hurdle for me. The arrow separates the signature and the body of the lambda expression.
Always remember : Linq methods are not executed until enumerated.
Watch out for using loop variables in a lambda. This is a side effect from deferred execution that is particularly tricky to track down.
3) Sure, Here are some of my answers that show linq method calls - some with xml.
List splitting
Simple Xml existence search
Xml projection - shape change
1) Those descriptions sound pretty accurate to me. Sometimes anonymous methods and lambda expressions will need to create a new type to put the target of the delegate in, so they can act as closures.
2/3) I would read up a bit until you're happy with delegates, anonymous methods and lambda expressions. I dedicate a chapter to the delegate-related changes in each of C# 2.0 and C# 3.0 in C# in Depth, although of course other books go into detail too. I have an article as well, if that helps.
As for examples - delegates are used for many different purposes. They're all different ways of looking at the same functionality, but they can feel very different:
Providing the code to call when you start a new thread
Reacting to UI events
Providing the filter, selection, ordering etc for a LINQ query
Providing a callback for when an asynchronous operation has finished
If you have any specific situations you'd like an example of, that would be easier to answer.
EDIT: I should point out that it's good news that you're only working with LINQ to Objects and LINQ to XML at the moment, as that means you don't need to understand expression trees yet. (They're cool, but one step at a time...) LINQ to XML is really just an XML API which works nicely with LINQ - from what I remember, the only times you'll use delegates with LINQ to XML are when you're actually calling into LINQ to Objects. (That's very nice to do, admittedly - but it means you can reuse what you've already learned.)
As you've already got C# in Depth, chapters 10 and 11 provide quite a few examples of using lambda expressions (and query expressions which are translated into lambda expressions) in LINQ. Chapter 5 has a few different examples of delegate use.
Read this...
http://linqinaction.net/
..and all you're question will be answered!!!

C#: What Else Do You Use Besides DataSet

I've found myself increasingly unsatisfied with the DataSet/DataTable/DataRow paradigm in .Net, mostly because it's often a couple of steps more complicated than what I really want to do. In cases where I'm binding to controls, DataSets are fine. But in other cases, there seems to be a fair amount of mental overhead.
I've played a bit with SqlDataReader, and that seems to be good for simple jaunts through a select, but I feel like there may be some other models lurking in .Net that are useful to learn more about. I feel like all of the help I find on this just uses DataSet by default. Maybe that and DataReader really are the best options.
I'm not looking for a best/worst breakdown, just curious what my options are and what experiences you've had with them. Thanks!
-Eric Sipple
Since .NET 3.5 came out, I've exclusively used LINQ. It's really that good; I don't see any reason to use any of those old crutches any more.
As great as LINQ is, though, I think any ORM system would allow you to do away with that dreck.
We've moved away from datasets and built our own ORM objects loosely based on CSLA. You can get the same job done with either a DataSet or LINQ or ORM but re-using it is (we've found) a lot easier. 'Less code make more happy'.
I was fed up with DataSets in .Net 1.1, at least they optimised it so that it doesn't slow as exponentially for large sets any more.
It was always a rather bloated model - I haven't seen many apps that use most of its features.
SqlDataReader was good, but I used to wrap it in an IEnumerable<T> where the T was some typed representation of my data row.
Linq is a far better replacement in my opinion.
I've been using the Data Transfer Objects pattern (originally from the Java world, I believe), with a SqDataReader to populate collections of DTOs from the data layer for use in other layers of the application.
The DTOs themselves are very lightweight and simple classes composed of properties with gets/sets. They can be easily serialized/deserialized, and used for databinding, making them pretty well suited to most of my development needs.
I'm a huge fan of SubSonic. A well-written batch/CMD file can generate an entire object model for your database in minutes; you can compile it into its own DLL and use it as needed. Wonderful model, wonderful tool. The site makes it sound like an ASP.NET deal, but generally speaking it works wonderfully just about anywhere if you're not trying to use its UI framework (which I'm moderately disappointed in) or its application-level auto-generation tools.
For the record, here is a version of the command I use to work with it (so that you don't have to fight it too hard initially):
sonic.exe generate /server [servername] /db [dbname] /out [outputPathForCSfiles] /generatedNamespace [myNamespace] /useSPs true /removeUnderscores true
That does it every time ... Then build the DLL off that directory -- this is part of an NAnt project, fired off by CruiseControl.NET -- and away we go. I'm using that in WinForms, ASP.NET, even some command-line utils. This generates the fewest dependencies and the greatest "portability" (between related projects, EG).
Note
The above is now well over a year old. While I still hold great fondness in my heart for SubSonic, I have moved on to LINQ-to-SQL when I have the luxury of working in .NET 3.5. In .NET 2.0, I still use SubSonic. So my new official advice is platform version-dependent. In case of .NET 3+, go with the accepted answer. In case of .NET 2.0, go with SubSonic.
I have used typed and untyped DataSets, DataViewManagers, DataViews, DataTables, DataRows, DataRowViews, and just about anything you can do with the stack since it firsts came out in multiple enterprise projects. It took me awhile to get used to how allow of it worked. I have written custom components that leverage the stack as ADO.NETdid not quite give me what I really needed. One such component compares DataSets and then updates backend stores. I really know how all of these items work well and those that have seen what I have done are very impressed that I managed to get beyond there feel that it was only useful for demo use.
I use ADO.NET binding in Winforms and I also use the code in console apps. I most recently have teamed with another developer to create a custom ORM that we used against a crazy datamodel that we were given from contractors that looked nothing like our normal data stores.
I searched today for replacement to ADO.NET and I do not see anything that I should seriously try to learn to replace what I currently use.
DataSets are great for demos.
I wouldn't know what to do with one if you made me use it.
I use ObservableCollection
Then again i'm in the client app space, WPF and Silverlight. So passing a dataset or datatable through a service is ... gross.
DataReaders are fast, since they are a forward only stream of the result set.
I use them extensively but I don't make use of any of the "advanced" features that Microsoft was really pushing when the framework first came out. I'm basically just using them as Lists of Hashtables, which I find perfectly useful.
I have not seen good results when people have tried to make complex typed DataSets, or tried to actually set up the foreign key relationships between tables with DataSets.
Of course, I am one of the weird ones that actually prefers a DataRow to an entity object instance.
Pre linq I used DataReader to fill List of my own custom domain objects, but post linq I have been using L2S to fill L2S entities, or L2S to fill domain objects.
Once I get a bit more time to investigate I suspect that Entity Framework objects will be my new favourite solution!
Selecting a modern, stable, and actively supported ORM tool has to be probably the single biggest boost to productivity just about any project of moderate size and complexity can get. If you're concluding that you absolutely, absolutely, absolutely have to write your own DAL and ORM, you're probably doing it wrong (or you're using the world's most obscure database).
If you're doing raw datasets and rows and what not, spend the day to try an ORM and you'll be amazed at how much more productive you can be w/o all the drudgery of mapping columns to fields or all the time filling Sql command objects and all the other hoop jumping we all once went through.
I love me some Subsonic, though for smaller scale projects along with demos/prototypes, I find Linq to Sql pretty damn useful too. I hate EF with a passion though. :P
I've used typed DataSets for several projects. They model the database well, enforce constraints on the client side, and in general are a solid data access technology, especially with the changes in .NET 2.0 with TableAdapters.
Typed DataSets get a bad rap from people who like to use emotive words like "bloated" to describe them. I'll grant that I like using a good O/R mapper more than using DataSets; it just "feels" better to use objects and collections instead of typed DataTables, DataRows, etc. But what I've found is that if for whatever reason you can't or don't want to use an O/R mapper, typed DataSets are a good solid choice that are easy enough to use and will get you 90% of the benefits of an O/R mapper.
EDIT:
Some here suggest that DataReaders are the "fast" alternative. But if you use Reflector to look at the internals of a DataAdapter (which DataTables are filled by), you'll see that it uses...a DataReader. Typed DataSets may have a larger memory footprint than other options, but I've yet to see the application where this makes a tangible difference.
Use the best tool for the job. Don't make your decision on the basis of emotive words like "gross" or "bloated" which have no factual basis.
I just build my business objects from scratch, and almost never use the DataTable and especially not the DataSet anymore, except to initially populate the business objects. The advantages to building your own are testability, type safety and IntelliSense, extensibility (try adding to a DataSet) and readability (unless you enjoy reading things like Convert.ToDecimal(dt.Rows[i]["blah"].ToString())).
If I were smarter I'd also use an ORM and 3rd party DI framework, but just haven't yet felt the need for those. I'm doing lots of smaller size projects or additions to larger projects.
I NEVER use datasets. They are big heavyweight objects only usable (as someone pointed out here) for "demoware". There are lot's of great alternatives shown here.

Categories

Resources