CODEWITHSUNDEEP
sqlvb.netvisual-studio-2010sql-server-2008strongly-typed-dataset
Kishore Kumar
Kishore Kumar

Reputation: 12874

Using Strongly typed DataSet in VB.Net Project

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..

Upvotes: 1

Views: 2695

Answers (3)

competent_tech
competent_tech

Reputation: 44931

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.

Upvotes: 0

Naval
Naval

Reputation: 344

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.

Upvotes: 0

Stefan
Stefan

Reputation: 11509

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.

Upvotes: 1

Related Questions