 |
| Flowchart of data-driven applications with my API automating process of Data Access |
Download file: http://bit.ly/1uAbKaY
Nowadays, people tend to use ORM providers such as LINQ, Entity-Framework, and other 3rd-party ORMs such as NHibernate, Dapper. This is mostly used by advanced developers who have extensive knowledge of ADO.net and decided to try ORMs, and especially to large-scale Enterprises to map or organize their objects with Standards. The downside of using the said provider is, it's only limited to SQL-Server without any support from Microsoft Access Database or other databases like MySQL and we still need to learn these new technologies to the extent that our time will be consumed given the timeframe we're given to finish a data-driven business applications.
What if I create the same standard too that could utilize their existing ADO.net knowledge for small-time developers? What if I could ease their pain of using these technologies who has a difficulty of using ADO.net? This could be the solution for starters.
My Purpose of making this project
Seeing as there are many programmers and developers who are having difficulties of utilizing ADO.net especially newbies who are new to ADO.net technology, I intended to ease their pain by creating a Standard that could simplify the whole process of ADO.net by the use of API in a form of library that manages the inner workings of ADO.net that I am going to write. Although, it will still use ADO.net as an underlying Data Access type.
I also intended to make use of this standardized way of Data Access to ease my work and design a better code flow by minimizing calls within the Data Access Layer since I tend to be meticulous with the design and architecture of my codes.
In short: TO SIMPLIFY the complicated codes and handling ADO.net properly
Target Audience
The project is targeted upon developers who are still either new to ADO.net environment or for developers who wanted to make their development more faster. Expert developers is also welcome to use the API and you may help me expand the project.
This is clearly not an alternative to ORM providers like Entity Framework and LINQ.
THE CONCEPT / HOW IT WORKS
One API to rule them all
 |
| Flowchart diagram where API comes into play is emphasized |
Presented based from the image above represents the whole function of the API that I am going to program. This will be written using either C#.net or C++(for performance purposes). But don't worry what language you'll be using since you can make use of my API regardless and it's passing through CLR.
The first layer, Initialization Stage is where you will declare your SQL queries and what provider will you be using. This is one of the main purpose and advantages of my API since you can specify what providers will you be using and API will take care the rest of the work. So, if you have multiple database providers within your project, you can reuse the API methods I've created to suit your needs without having much extensive calls within ADO.net library.
The second layer, Provider Specification Stage lists the supported and compatible providers you can use in my API.
The third layer, API Stage interprets and bridges data connections between the database and its respective providers based from the parameters you've provided during the Initialization Stage. Depending on your needs, you can make use of methods that are accessible to you. For example, if you intend to display the data, you can simply call getDataTable() method and put it in DataGridView datasource if you are using one.
The fourth layer, SQL Query type Stage lists the available SQL types that are accessible to you.
And finally, the fifth layer, UI Layer Stage displays the table queries you've requested or changes that you've made.
Advantages of using my API
- Centralized and organized code flow
With this, you don't need to worry about the inconsistencies of your ADO.net codes, whether you forgot to open the connection or closed, or whether the DataSet is filled or not. In fact, you don't have to code those things entirely since these will automatically be handled within the API.
Also, this can have a great impact in your code architecture. You don't need to write ADO.net codes in every object events, or each time a Button event occurs. Needless to say it's automatically handled. Don't worry about it.
- Compatible with any providers
Another thing to note is that this is compatible with any providers you specify and the API can automatically handle it for you depending on the provider you've specified during Initialization. So, you don't need to write the whole ADO.net codes like creating using System.Data.SqlClient for SQL Server and creating another ADO.net codes(using System.Data.OleDb) for MS Access. It's already handled.
- Minimal code effort
Minimal code effort can give you an extra mile in creating a responsive System in just a short period of time since I make sure that you don't need to write the whole ADO.net codes in order to communicate with the Database. Everything that you need to do is provide an SQL Statement, Database provider, and Connection String and you're good to go!
- It makes the database access less error-prone
Since there will be no pesky setups and handlers like handling the open() and close() connections needed for this, you can safely assume that your Data Access Layer lessens the probability of error-prone. Thus, you'll find yourself focusing on constructing more on its Business Logic.
Restrictions or Limitations
- Cannot Auto-Generate objects based from the query
During the design stage of the API, I devised a theory that could further simplify the whole process of ADO.net. What if, my API had also the capabilities to generate objects? I think this is impossible since the query will be resolved during runtime not when you are constructing a Data Access using my API. So, what will happen is you're going to use DataRow object with its corresponding index column to access them. This is the whole purpose of why ORMs like LINQ were invented though.
- No database mapping involved
I don't intend to compete with existing ORM technologies. I only intend to simplify Data Access without the use of mapping for developers who make use of hard-coding.
DONATE
And don't forget to hit the donate button if my API prove to be useful in your development. :)
No comments:
Post a Comment