Someone I know wants to use diconnected recordsets in an application. To me it sounds like if I have a ORM tool there would really be no need to even touch disconnected recordsets. The way I understand it with ORM the ORM takes care of not hugging connections for unnecessarily long amounts of time, solving the need for a disconnected recordset. Is there an instance in which you would still want to use a disconnected recordset?
A fabricated ADO recordset can be a good choice of container object for data, as an alternative to a VBA Type (struct), Collection, Dictionary, etc i.e. strongly data typed nullable fields** with built-in support for filtering, sorting, searching, output to formatted text/xml/array, paging , cloning, etc. A fabricated ADO recordset is disconnected by definition.
Perhaps this isn't quite what you had in mind but it is a valid answer to your question i.e. an example of when you would still want to use a disconnected recordset, even though you have an ORM.
** Similary, ADO Parameter objects are a usual alternative for the Variant type in that, unlike VB intrinsic types, they can be both strongly data typed and nullable.
I'd consider using a recordset in small "assemble and forget" applications or when you have simple reporting needs like read-only grid views.
That includes any application where it feels like the quickest thing you can do, and you don't see a reason it will change later on.
However, if you are going to build a slightly advanced, maintainable, robust application, with business logic and the like, don't go with recordsets.
But sure, there's still use for it..
Related
I have recently decided to re-develop an access VBA application in VB .net with DevExpress.
I have managed to figure out databinding with the raw tables. However, I am struggling with the queries.
I have tried the query builder, but I dont have the option to save them and bind object to it. I assume it works this way? As it did in access? Or is the query builder there simply to help you format the SQL text?
I am trying to bind a DataGrid to a simply join query without any luck.
Can you someone point me in the right direction?
Thanks.
There are two main approaches that I can think of. One is to use datatables, and the other is to use domain objects.
Datatables are quick to write, can easily handle most of the heavy lifting for you (including CRUD operations) and are pretty scalable, as changes to the underlying object can be handled relatively easily.
DataTable dt = new DataTable();
Domain Objects (aka POCOs) take a lot of up-front work but typically in the log run make for a more bulletproof and robust solution. Plus, there are frameworks and even Micro ORMs that will do much of the heavy lifting for you, if you choose to use them.
List<DomainObject> do = new List<DomainObject>();
These work with tables, views or queries. You mention you have this figured out for a table, so I'm guessing you have already sort-of gotten this far.
So, first step -- figure out which direction you want to go. (pick domain objects)
Second step -- I recommend using a binding source (System.Windows.Forms.BindingSource). Make your data table / collection the DataSource for the binding source.
Third step, make the binding source the data source for your grid. If you are using a Domain Object, you'll see the columns populate automatically.
From there, once the datatable or collection is populated, you can assign it as the data source for the binding source, and .NET and Dev Express will take care of the rest for you.
bindingSource1.DataSource = dt;
or
bindingSource1.DataSource = do;
Now if you're talking CRUD operations -- that's a horse of a different color. You still use these as building blocks, but this is in no way a comprehensive answer for that.
By the way, the code above is C#, so you need minor tweaks to get this to be VB. I don't speak VB, otherwise I would have just done it like that to begin with.
For a hobby project I am building an application to keep track of my money. Register everything that comes in and goes out. I am using sqlite as a database backend.
I have two data access models in mind.
Creating one master object as a sort of database connector, which contains methods which execute the queries and provide the required sets of data as a list of objects
Have objects who need data execute the queries themselves
Which one of these is 'the best' and why? Or are there different, better models out there?
The latter option is better. In the first option, you would end up having to touch your universal data access object for just about any update to the code that wasn't purely a change in display logic. If you have different data access objects, then you will have much more testable, maintainable code.
I suggest you read up a bit on the model-view-controller paradigm. The wikipedia article on it is a good start: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller.
Also, you didn't say which language/platform you were coding in, but most platforms have numerous options for auto-generating a starting point your data access classes from your database. You may find something like that useful.
Much of a muchness really, the thing to avoid is having the "same" sql sprinkled all over your code base.
The key point is. You've just added a new column to Table1. When you do Find In Files "Table1", how many hits are you going to get and where.
If you use one class and there's a lot of db operations, it's going to get very messy very quickly, but if you have one interface (say IModel) with one implementation, you can swap backends very easily.
So how many db operations, and how likely is it you will move away from SqlLite.
Is using strongly typed dataset is good.
Currently I am working on a project developed using VB.Net in Visual Studio 2010.
Previously they were using Sql queries directly into SqlCommand of System.Data.SqlClient, but then after i shifted everything to Strongly Typed DataSet and started using TableAdapters every where..
Now i just wanna ask that is this way is good for a project...
Or Should i shift back to old ones using Just SqlCommands
Or Is there any way to make Sql DataBase in a good way because its an ERP and most of the code is for Data Access..
We use strongly typed datasets all the time now.
After shifting to this behaviour it felt really bad to have SQL-querys in code instead of having it done by the table adapter. But there is a bit overhead with datasets so I guess booth ways are good for different solutions.
Its really nice to have intellisence on all fieldnames and if you change a tableadapter so it returns something different you get design-time errors everywhere where you need to change the code to reflect the change, instead of finding out runtime when the customer is running the program.
There are so many win win-things with strongly typed datasets so I'll never go back.
Table adapters .... make a lot of mess with bigger databases, also updating the table structure also causes confusion.
I would recommend to use some auto code generators for the CRUD Operations.
To me your old pattern looks better than switching altogether to table adapters and strongly typed datasets.
If you ever want to move your data across the wire to other platforms (silverlight, web services, wcf services, etc), then using any kind of dataset will box you into a corner.
The way that we have resolved this is to have classes whose list of properties match the database exactly. To move the data in and out of the database, we use reflection to either match stored procedure parameters or generate dynamic SQL statements, depending on the circumstance and platform.
When a database table is changed, the developer making the change is also responsible for updating the class structure and vice-versa.
In order to reduce the amount of hand-coding required, we use the code generation capabilities of CodeSmith to generate classes from the database and create the basic implementations of our standard add/update stored procedures that require field enumeration.
As an added benefit, this approach removes the tight link between the database and business object structure. We are able to use our same data access code and business object classes against SQL Server, Oracle, Sqlite, and SqlServerCE databases. This code is used to create applications in Windows, PocketPC, Web, iPad, and Android apps; all of the mobile apps use local databases specific to the platform, but using the common data access code.
It is a bit more work to setup initially, but it will pay significant dividends in the long run.
I am putting some heavy though into re-writing the data access layer in my software(If you could even call it that). This was really my first project that uses, and things were done in an improper manner.
In my project all of the data that is being pulled is being stored in an arraylist. some of the data is converted from the arraylist into an typed object, before being put backinto an arraylist.
Also, there is no central set of queries in the application. This means that some queries are copy and pasted, which I want to eliminate as well.This application has some custom objects that are very standard to the application, and some queries that are very standard to those objects.
I am really just not sure if I should create a layer between my objects and the class that reads and writes to the database. This layer would take the data that comes from the database, type it as the proper object, and if there is a case of multiple objects being returned, return a list of those object. Is this a good approach?
Also, if this is a good way of doing things, how should I return the data from the database? I am currently using SqlDataReader.read, and filling an array list. I am sure that this is not the best method to use here, i am just not real clear on how to improve this.
The Reason for all of this, is I want to centralize all of the database operations into a few classes, rather than have them spread out amongst all of the classes in the project
You should use an ORM. "Not doing so is stealing from your customers" - Ayende
One thing comes to mind right off the bat. Is there a reason you use ArrayLists instead of generics? If you're using .NET 1.1 I could understand, but it seems that one area where you could gain performance is to remove ArrayLists from the picture and stop converting and casting between types.
Another thing you might think about which can help a lot when designing data access layers is an ORM. NHibernate and LINQ to SQL do this very well. In general, the N-tier approach works well for what it seems like you're trying to accomplish. For example, performing data access in a class library with specific methods that can be reused is far better than "copy-pasting" the same queries all over the place.
I hope this helps.
It really depends on what you are doing. If it is a growing application with user interfaces and the like, you're right, there are better ways.
I am currently developing in ASP.NET MVC, and I find Linq to SQL really comfortable. Linq to SQL uses code generation to create a collection of code classes that model your data.
ScottGu has a really nice introduction to Linq to SQL on his blog:
http://weblogs.asp.net/scottgu/archive/2007/05/19/using-linq-to-sql-part-1.aspx
I have over the past few projects used a base class which does all my ADO.NET work and that all other data access classes inherit. So my UserDB class will inherit the DataAccessBase class. I have it at the moment that my UserDB class actualy takes the data returned from the database and populates a User object which is then returned to the calling Business Object. If multiple objects are returned then these are then a Generic list ie List<Users> is returned.
There is a good article by Daemon Armstrong (search Google for Daemon Armstrong which demonstrates on how this can be achived.
""http://www.simple-talk.com/dotnet/.net-framework/.net-application-architecture-the-data-access-layer/""
However I have now started to move all of this over to use the entitty framework as its performs much better and saves on all those manual CRUD operations. Was going to use LINQ to SQL but as it seems to be going to be dead in the water very soon thought it would be best to invest my time in the next ORM.
"I am really just not sure if I should create a layer between my objects and the class that reads and writes to the database. This layer would take the data that comes from the database, type it as the proper object, and if there is a case of multiple objects being returned, return a list of those object. Is this a good approach?"
I'm a Java developer, but I believe that the language-agnostic answer is "yes".
Have a look at Martin Fowler's "Patterns Of Enterprise Application Architecture". I believe that technologies like LINQ were born for this.
I am involved in development of a tiered application that uses LINQ2SQL separated from the web server with a NET.TCP Binding on WCF.
My questions are:
What sort of measures should I take
to achieve the best performance?
Since the entity objects returned by
the LINQ need to be converted to a
IEnumerable list to be serialized
everytime, is there anyway to remove
this dependency?
1) Concentrate on a properly normalized database design. I would say that when you are forced to make design tradeoffs in your code vs. database design, if performance is your goal, make tradeoffs in your object design instead of your database design. Understand that you aren't going to be able to do a proper supertype/subtype database design which will work with Linq to SQL (I'm told you need to use the EF instead).
2) Depends what you mean here. If you're asking how you would serialize anonymous classes across the wire, the easy answer is: "you can't, so don't try". If you want to put lists of objects across the wire, just use the ToArray() extension method on your IEnumerable collections to ship arrays of your business objects over the wire.
Linq to SQL is very slow unless you compile queries. Otherwise your application will be CPU bound as most of the time will be spend converting Expression trees into SQL.
We are talking about 10x performance gain if you use compiled queries. Try it :)