We have Oracle 11 as database for our third party server application. The interactions for db is only allowed through the interops DLLs provided by vendor. No direct access to database is allowed. We need to connect to the database using those DLLs for creating or deleting objects inside the database. I am wondering if I can use Nhibernate by writing some wrappers about those DLLs. No SQL queries are also allowed. Can this be done?
Who is vendor? Not Oracle I guess, but your "third party" providing the "application server" software.
In such case this looks like they want to forbid direct SQL access to their application DB. So there is no point trying to use an ORM such as NHibernate, it would be from their point of view almost like directly querying the DB.
Your "best" option is to ask them if they can provide their own NHibernate database driver, but their answer will very probably be "No".
Related
I know we cannot access directly to a database with Silverlight. Linq 2 SQL doesn't exist for Silverlight but can I use other things ? I heard too about RIA Services and ADO.net but I don't think they are implemented for a Linux Server.
Thanks for your future answers.
If you can create a REST or SOAP web service that exposes data from the database, then Silverlight can access that service with its networking stack.
You will need to put a few things together.
First if you want to create a Model then you will be looking for an ORM that works itn Postgresql there a probably a few, I stubbled on Storm but there are probably others.
You will then need to expose the model using SOAP again there are a few implementations of SOAP you could use. (In fact at this point I'm going to tweak your tags to target this question better, this not a Linq-To-SQL, c#, or ado.net question).
I currently developed an app that connects to SQL Server 2005 database, so my DAL objects where generated using information from that DB.
It will also be possible to connect to an Oracle and MySQL db, all with the same table structures (aside from the normal differences in fields, such as varbinary(max) in SQL Server and BLOB in Oracle, and so on). For this purpose, I already defined multiple connection strings and multiple SubSonic providers for the different DB's the app will run on.
My question is, if I generated my objects using a SQL Server database, should the generated objects work transparently with the other DB's or do I need to generate a different DAL for each database engine I use? Should I be aware of any possible bugs I may encounter while performing these operations?
Thanks in advance for any advice on this issue.
I'm using SubSonic 2.2 by the way....
From what I've been able to test so far, I can't see an easy way to achieve what I'm trying to do.
The ideal situation for me would have been to generate SubSonic objects using SQL Server for example, and just be able to switch dynamically to MySQL by just creating at runtime the correct Provider for it along with its connection string. I got to a point where my app would correctly connect from SQL Server to a MySQL DB, but there's a point where the app fails since SubSonic internally generates queries of the form
SELECT * FROM dbo.MyTable
which MySQL doesn't support obviously. I also noticed queries that enclosed table names with brackets ([]), so it seems that there are a number of factors that would limit the use of one Provider along multiple DB engines.
I guess my only other option is to sort it out with multiple generated providers, although I must admit it does not make me comfortable knowing that I'll have N copies of basically the same classes along my project.
I would really love to hear from anyone else if they've had similar experiences. I'll be sure to post my results once I get everything sorted out and working for my project.
Has any of this changed in 3.0? This would definitely be a worthy reason for me to upgrade if life is any easier on this matter...
I am impressed by the way we programmatically access lists in SharePoint. I percieve it as a Data Access Layer, while modeling the database is as simple as defining the columns in the List.
I am looking for a tool OR an application that would give me similar interface to a database. Basically, for some reason I cannot use SharePoint and I don't wish to take up the responsibility of modeling, deploying and maintaining the database. I find the SharePoint way of persistence management acceptable and exciting.
Can anyone suggest me something even close to this.
BTW, my application is on ASP.Net and my preferred RDBMS is MS SQL Server.
If you don't want the overhead and expense of a Sharepoint installation, 90% of the time all you really need is WSS 3.0 (free with a windows server license).
For auto generated entity classes you can use Linq To Sharepoint (SPMetal)
For hand written POCO entities you can try using SharepointCommon ORM
Use NOSQL database like MongoDb or CouchDB which are schema less, allowing you to freely add fields to JSON documents without having to first define schema.
We have been using nhibernate for almost a year now.
I wuld like to know that are there any vulnerabilities that could be injected(like SQL injection etc.) using web application.
I just want to secure any nhibernate injection through web application if there are.
I think that one of the requirements of a proper OR/M manager, is to make sure that all queries that can be executed using the OR/M manager, are properly secured against SQL injection.
NHibernate generates parametrized queries for SQL Server, so that is secure.
Offcourse, I don't know how other providers (for other DBMS'es) generate ...
As Frederik said, the queries are parametrized so you have roughly the same risk of a sql injection attack as you do with a stored procedure in SQL Server. This means you are safe from direct SQL injection, but neither protect you from latent sql injection. For more info on latent SQL injection, check out the comments of Jeff Atwood's blog post here: Give me parameterized SQL, or give me death
The biggest security concern with NHibernate is that you have to expose a SQL account to your application that can select/insert/update/and delete (if not doing soft deletes) on your database tables. With stored procedures you can expose an account that only has rights to execute stored procedures. This is not a problem for many places, but some places may have strict policies against direct table access.
Traditionalist argue that stored procedures provide better security than if you use a Object Relational Mapping (ORM) framework such as NHibernate.
To counter that argument what are some approaches that can be used with NHibernate to ensure that proper security is in place (for example, preventing sql injection, etc.)?
(Please provide only one approach per answer)
Protect your connection strings.
As of .NET 2.0 and NHibernate 1.2, it is easy to use encrypted connection strings (and other application settings) in your config files. Store your connection string in the <connectionStrings> block, then use the NHibernate connection.connection_string_name property instead of connection.connection_string. If you're running a web site and not a Windows app, you can use the aspnet_regiis command line tool to encrypt the <connectionStrings> block, while leaving the rest of your NHibernate settings in plaintext for easy editing.
Another strategy is to use Integrated Authentication for your database connection, if your database platform supports it. That way, you're (hopefully) not storing credentials in plaintext in your config file.
Actually, NHibernate can be vulnerable to SQL injection if you use SQL or HQL to construct your queries. Make sure that you use parameterized queries if you need to do this, otherwise you're setting yourself up for a world of pain.
Use a dedicated, locked-down SQL account
One of the arguments I've heard in favor of sprocs over ORM is that they don't want people to do whatever they want in the database. They disallow select/insert/update/delete on the tables themselves. Every action is controlled through a procedure which is reviewed by a DBA. I can understand where this thinking comes from... especially when you have a bunch of amateurs all with their hands in your database.
But times have changed and NHibernate is different. It's incredibly mature. In most cases it will write better SQL than your DBA :).
You still have to protect yourself from doing something stupid. As spiderman says "with great power comes great responsibility"
I think it's much more appropriate to give NHibernate the proper access to the database and control actions through other means, such as audit logging and regular backups. If someone were to do something stupid, you can always recover.
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
Most ORM's handle SQL injection by creating parameterized queries. In NHibernate, if you are using LINQ to NHibernate or the Criteria/Query over methods of writing queries, the queries are automatically parameterized, if you are dynamically creating HQL/SQL queries yourself you are more vunerable and would have to keep in mind that your queries would have to be parameterized.
OWASP mentions one form of SQL injection vulnerability in the context of ORM tools (and gives HQL injection as an example): http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection