I have a database which does not provide (yet) c# client library, only a binary tcp or http rest protocol.
I have to write an application that can perform various operations on the DB : CRUD, management, etc.
These operation are expressed in a sql query, with select/insert/update/delete and custom keywords for DB-specific operations.
I'm wondering what is the path to this result. I can ask the question in two point of views : in an ideal world, and in a practical world.
I'd appreciate any feedback !What is the recommended approach, problems encountered, etc.
PS: I'm thinking over these approaches :
writing a custom ADO.Net provider (IDbCommand, IDbConnection, etc.)
writing a custom linq provider (which relies on the former)
maybe writing a EF provider
Linq is just language integrated query. It is syntax to express query but in case of database querying it just creates expression tree which must be translated to SQL and executed somehow. For this execution ADO.NET provider is used. The same states for Entity framework which rely on ADO.NET provider to access the database. So if you want to create some implementation you should start with ADO.NET provider anyway.
Related
Is there a tool or framework to expose SQL Server tables and its data of as oData. Consider that tables are generated dynamically so using OR Mapper Entity Framework is not an option.
We need a mechanism to expose data as OData without generating C# classes.
There are a number of options here.
From a coding perspective, you can build something generic. .Net (C#) wraps OData support around the IQueryable interface and the [EnableQuery] attribute. The Pseudo code below demonstrates how you can do this generically with WebAPI2. A working demo can be stood up in minutes:
[EnableQuery(PageSize = 100)]
public IQueryable Get()
{
var data = (IQueryable)<get any data from the DB as IQueryable>;
return Okay(data, data.GetType());
}
Keep in mind that the filtering etc can end up being performed in memory, so trying to push as much of the filtering back to the database will give better performance. I have mainly used this with strongly typed objects and Entity Framework pushes all the filtering to the DB - very powerful and very quick. Keep in mind that OData is very flexible and you need to optimise your database indexes and queries for your common use cases.
From a Database perspective, if you are running in Azure, you have OData a few clicks away. See this article. Further Azure Table Storage's raw format is OData from the get go. Beware there may be limitations, for example, I think OData results from SQL Azure are paged to 50 rows to avoid denial of service type scenarios that thrash your database, especially for OData queries over non indexed data.
If your SQL is on premise, I don think there is anything out of the box, however there are a number of vendors that offer connectors. Here is an example from a quick Google. I have no affiliation with them.
Does mysql.data.entity have built in protection against injection attacks. I feel like it should as it doesn't pass in literals, but rather objects so they should never touch SQL, but I'm not sure.
Whilst one cant be certain without access to the MYSQL provider code, it is extremely unlikely there are issues with regard to injection.
The EF provider specification. and the
SQL generation based on trees approach.
And the sample would suggest it is not likely to be vulnerable.
Of course when one exposes direct SQL again eg via
dbContext.Set.SqlQuery(); // or equivalent in < ef6 versions
then all bets are off.
I'm building a data access layer and need to be able switch between two providers in different environments.
How do I structure this? I'm using a repository pattern and have e.g. a CarRepository class and a Car class. The CarRepository class is responsible for saving, deleting and loading from the database.
I have a Database class, responsible for connecting to the database, and executing the query (sending a SqlCommand for SQL Server). The SQL syntax for the underlying databases is different and the parameter syntax is also different (SQL Server uses # and MySql uses ?).
I would like an approach where I can make the least effort in making my application run on both platforms.
The obvious method is making a MySqlCarRepository and a SqlServerCarRepository, but that introduces a heavy amount of maintenance. Are there any good approaches to this scenario? Maybe keeping a static class with static strings containing the SQL statements for the different SQL flavours? (how about parameter syntax then?)
Any advice is welcome
(Please note that ORM (Nhibernate, Linq2Sql etc) is not an option)
The approach I follow is to first-of-all use the ADO Provider Factories to abstract the data access implementation. So I will use IDbConnection and so forth in the code.
Then I have an abstraction for a query. I can then use Query objects that contain the actual sql statements. These Query objects are created from RawQuery or various query builders (insert/update/delete/etc.) that have implementations for each provider type. The specific raw queries will need to be coded and obtained specific to the DB you need since there is no gettin passed that.
There is quite a bit of leg work involved in coding this 'plumbing' and I have not had a situation where I actually require different platforms so I have not bothered coding some small bits that I know need some ironing out but you are welcome to contact if you are interested in seeing some code.
Can you use any code generation tools?
I used to use Code Smith in another life and had templates that would generate POCO objects from DB tables, repository classes for each object and stored procedures. Worked alright after fine tuning the templates, and there were plenty examples on the net.
But this was way before I saw the light with NHibernate!
A pattern for accessing multiple database types is the DAO (Data Access Object) pattern. This could suit your particular need if you can't/don't use an ORM. The following article explains the pattern for Java but it is still very relevant for C#:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
I'm opening a discussion here on a subject I couldn't find any answer good enough to be called a final answer: MySQL and .NET.
While I know there is a lot of ways to make this connection, I'm trying to find a list of pros and cons of each approach.
I've been using ADO.NET with the MySQL NETconnector since the beggining of my project, and everything was ok when the database was new and didn't have many records. But now I'm facing a situation where the number of records grows exponentially, and I found other way of querying against the database, which is the ODBC connector. Using the ADO.NET + NETConnector solution I had my O/RM and didn't have to write my queries, while ODBC makes my code look awful now (since I didn't switch completely to ODBC, I have Linq queries and plain SQL queries inside my code).
Is there any solution (free or not) where I can have both an O/RM without the need of writing SQL queries myself and the speed of ODBC?
What you should be doing is using the MySQL ADO.NET Connector and storing your queries in the database in the form of stored procedures. Version 6.0 of the MySQL connector also supports The Entity Framework. If you are interested in using the Entity Framework, check out this link which describes how to set that up.
NHibernate
Update to Comments
NHibernate Proxy Generators
It is a byte code generator for your object model that allows NHibernate to perform lazy loading and other operations. The link provided explains the benefits.
Castle and LinFu are two different implementations of those Proxy Generators.
While NHibernate does not have coincide documentation all the information on how to use it, is on the internet. This could be a barrier to usability for some people though. I understand more about NHibernate because of my past experience with Hibernate.
I am building a forum, and it has got 4 tables: Users, Threads, Comments, Topics.
I established the connection and the pages.. I started using the ADO.net way to insert data and select data..but then I found that to make more complex manipulations i need to know SQL. So I was looking for another way, and I found that I can open Visual Studio 2010, add Linq to SQL file that produced object relational designer. I read about how to write code, and I saw that I simply need to use a using statement with DataContext object with a simple code to update, add, delete rows in the tables.
I wanted to know, what are the advantages of using one way of querying over another?
ADO.NET gives you low level control over your queries. If query speed is going to be of importance, this is where you want to be. If you speed is not very important, but rapid development and an Object Relational Model is, LINQ to SQL is a safe bet.
I would recommend Linq to SQL over ADO.NET though.
Development is rapid and thinking in an ORM way is natural.
If your queries are too slow, using the .ExecuteQuery method will allow you to pass in a sql statement that you have optimized as if you were doing it in the ADO.NET way. I have had much success with Linq to Sql.
Also I would look at Entity Framework. It gives you more control over your objects and how they are implemented, used and handled than Linq.
LINQ to SQL is part of the ADO.NET family of technologies. It is based on services provided by the ADO.NET provider model. You can therefore mix LINQ to SQL code with existing ADO.NET applications and migrate current ADO.NET solutions to LINQ to SQL. The following illustration provides a high-level view of the relationship.
Refer to the following:
ADO.NET and LINQ to SQL
Advantages & Disadvantages of LINQ
Performance of LINQ to SQL over Normal Stored procedure
LINQ-to-SQL and Stored Procedures
LINQ to SQL is great in that it generates alot of the plumbing code for you. But it is basically the same as using straight up ADO.NET/SQL. To do more complex data manipulation in LINQ to SQL you have to know how write complex joins in LINQ just as you would in SQL.
Look into Entity Framework - it might give you a higher level of abstraction that you are looking for.
The two are on different abstraction levels. ADO.NET is the lowest level of data access in .NET. Anything else will build upon it.
Every abstraction should give you power to express higher-level concepts at the cost of lower level concepts.
If I sound like a philosopher it's because it's Friday.
In addition to Entity Framework, you can take a look at NHibernate (another .net Object Relational Mapper). It's been around longer than EF so it's a bit more mature, but it isn't developed by Microsoft if that matters to you.