简体   繁体   中英

Better Data access components for windows desktop application

Which one can be the better one data access component for desktop application and why?

1.) For MS Access 2007: ADO, OLEDB, DAO

2.) For MSSQL 2005: ADO, OLEDB, DAO

As far as the Access part of his answer, I disagree with Hans.

If you are using Access, you'd be much better off using DAO or ADO. DAO is the choice of many as it is usually easier and is the native data access model for MSAccess. Look at Is it better to use ADO or DAO in Access 2007? for a more thorough discussion.

DAO is hopelessly antiquated, it doesn't support the engines you listed. OLEDB and ADO are complementary, OLEDB provides the dbase engine interface, ADO is a grab bag of the classes you'll use in your code to program the dbase interface. ADO.NET in the .NET framework.

For Access you'd use the classes in the System.Data.OleDb namespace, your connection string uses the ACE provider. For SQL you'd best use the classes in the System.Data.SqlClient namespace. Visit connectionstrings.com for help with configuring the connection strings.

Ask yourself: What data access features do I need, and choose your layer based on that. MS Access is file-based data storage, so if you have more than one user using your app then Access is a bad choice. I would steer clear of MSA and focus on newer technologies.

MSSQL is much better, as it is scalable, supports multiple concurrent users, and has additional management tools like backup and reporting services. SQL 2005 Compact Edition allows you to attach the database at run time, great for single instance desktop apps.

A third DAC you might want to look at is SQLite also for file-based solutions or desktop applications.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM