I want to use an ORM, and have been looking at EF 4. Is this platform scalable. I see a lot of stuff on the web, but everything looks very biased in one way or the other. Anyone know of benchmarks or non-subjective information.
On that point, does EF prevent SQL injection or XSS. I know that it used parametrized queries, but is that enough?
Any help is appreciated.
Okay so i see two questions here.
Is EF Scalable
Very difficult (and subjective) to answer, but IMO yes.
Here's a few reasons why:
Utilizes a common querying language (LINQ)
Allows for multiple providers (SqlServer, Oracle, etc)
Allows bi-directional mapping (code first, model first, database first)
Includes "classic ADO.NET" support (stored procedures, Entity-SQL)
The main real benefit in scalability is how the framework is built on LINQ-to-Entities. When you write queries, you are not writing against SQL Server or Oracle, you are writing against the Model. Depending on what Provider you have setup (in web.config), EF will translate these model queries into the appropriate T-SQL (or P-SQL).
Therefore (theoretically), you could write code against SQL Server, then change the web.config provider to Oracle, and your code should work. Obviously this isn't the case for Entity-SQL though (as you are writing T-SQL, not LINQ).
Does EF prevent SQL injection or XSS
No ORM tool can really "prevent" SQL Injection attacks - they can only provide the developer with the tools to prevent it.
As with classic ADO.NET where you use parameterized queries, Entity Framework has Entity-SQL, which allows to to execute pre-generated SQL, stored procedures, etc.
In this scenario, you need to use parameterized queries to prevent SQL injection. For most EF work, you will be writing queries with LINQ, which is a lot safer because it gets hydrated through a lot of stages before it becomes SQL.
XSS is exploited on the client-side via things like injected JavaScript, dodgy emails, etc. Has nothing to do with Entity Framework. Prevention of XSS is done on the client-side with things like HTML encoding.
No. ORMs are not a panacea for scalability. There is such a things called the impedance mismatch of objects and databases which has been around for many years. ORMS try to solve this by providing magic code generation/mapping solutions that give the appearance of just working with objects.
In a multi-tier environment with many client programs and a single/many server scenario, for every change that has to be committed to the database, checks need to be performed to make sure that your not over writing someone elses change on the data, or trying to update data that has been removed. This is not a new problem introduced by ORMs but one which appears many many times throughout the ages of updating databases in N-Tier environments. ORMS do not solve this problem. In some cases, if the ORM is the single entry to the Database, the ORM becomes a bottle neck. This means that to create a scalable architecture using an ORM becomes problematic as having DB checks performed on the ORM means that the update anomaly checks could be by passed if your using an N-Tier ORM solution where you have duplicate ORM tiers.
For the reasons above, this is why we use stored procedures. But if your using stored procedures, which naturally obfuscate the underlying data structures of the database then this increases the impedance mismatch of objects and database entities. One thing about using stored procedures and relying on table locking/row rocking, some of the update scenarios are solved, as we shift the bottle neck to the performance of the underlying database design.
So whats the answer. Don't use objects for databases. Object are great for analysis, bad for code design when interacting with RDBMS databases.
If your really thinking SQL and RDBMS data solutions are a problem, which in some scenarios they are, take a look at some of the NOSQL solutions out there. Still not a panacea for all problems, but in some cases they provide a better solution than a straight SQL solution.
Objects are not the answer to all problems. Step back from your code, take a look at what your trying to do, and think if an object is the right approach.
As for security, no ORMS do not aid security. Although they do help prevent some forms of injection attacks.
Related
We are a small team working on a very tight deadline to develop a large web application in .NET. We are using multiple databases (one per client) so our requirements are slightly different than most applications. The databases will only be used for this particular application so it doesn't matter if they are tightly coupled with the application. The main deciding factors are speed of development, long-term maintainability, and security. There are 3 options we are considering:
Option 1 - LINQ to SQL
None of us have any experience with LINQ, but we have been researching it and it seems like a good option and not too difficult to learn. Worth the risk of learning a new method on a tight deadline?
Option 2 - Stored Procedures
Seems like it could be a nightmare to maintain with the multiple database setup (or would it?) and it may slow down development to work in another environment as we don't have a dedicated database developer. Basic CRUD queries would be generated by code generator which is an advantage.
Option 3 - Inline Queries
This method would be the fastest to develop but I know people are generally against hard-coded queries nowadays and I fear we may suffer in the long term with maintainability issues. Basic CRUD queries would be generated by code generator.
Please let me know if there are any factors we are missing. What solution seems the most appropriate for this project?
If you have a tight deadline don't try something new. Ask the devs to study Entity Framework at home and in their spare time and try it in next project. Meanwhile do what you know best and have used in past successfully.
Inline queries are not bad if they are decoupled in a DAL assembly.
Since #Hasan Khan covered the primary answers regarding SQL. I'm going to throw out a somewhat different answer. Another option is to consider usage of RavenDB, a NoSQL db. It has the concept of Tenant databases inherently baked into it. Which from your requirements it sounds like this is the intended goal.
I am only starting with Entity Framework and I appreciate the direct mapping of code to the tables in my database. What I do not see just yet is the practicality of having to use EF over stored procedures and I would appreciate anyone's opinion about this. I am not being lazy and I am searching this myself at the moment. Thought I can post the question and hear from others as well.
My case is EF being an ORM is most suited to mapping in the tables in my database. But in a live web server many requests can happen at one time that may be taxing the database in having to compile the text queries prior to executing them compared to just simply executing stored procedure which are pre-compiled already. EF can also map to SPs but I feel that this is somewhat diminishing the value of ORM.
I would really appreciate an eye-opener in this case.
You might find Jeff's commentary on the subject helpful: http://www.codinghorror.com/blog/2005/05/stored-procedures-vs-ad-hoc-sql.html.
His point is basically that stored procedure's can be seen as a kind of premature optimization, and you really should make sure this is the performance bottleneck in your application before going that route. For instance, there are frameworks available to mock up 1000's of simultaneous web requests to see how your database will really perform under load in one situation versus the other.
Just because EF isn't using sprocs, it doesn't mean that the parameterised queries it runs won't get compiled and cached. SQL Server has got a lot more clever about that over the years.
One possible approach:
- dynamic sql for single objects
- SPs for parameterized lists and orders
The value of the ORM is usually its simplicity in creating the object model. One approach is described here: http://www.codeproject.com/Articles/362034/Populating-a-business-logical-layer-from-stored-pr
Which one is preferable for Enterprise CMS development:
LINQ or SP?
Generally what I do is LINQ to Views and LINQ to Stored Procedures. It's not a question of what is preferred because LINQ solves how to manage the data once it's queried where Stored Procedures are run on the SQL side to allow for query manipulation (or for me, mostly saving) of data which takes away from having the code to do it which is slower.
I would say you would want to use both if necessary. Are you saving to Entities that require multiple tables saves as one Entity? If so, use Stored Procedures with LINQ. If you're using 1 to 1 Entity relations to your tables then just use LINQ.
Stored Procedures can be used with Linq2Sql (and Entity Framework), so it isn't a choice of one or another.
I would cache the results from the database for a CMS as you likely to get the same data requested over and over again (cache the dataset, or use page caching, or cache the objects if using LINQ).
Then it doesn't matter if you use LINQ or an SP, but I would just use LINQ.
For simple CRUD table(no joins !!!) operations LINQ to SQL is fine, however for anything more complex (needing joins) I always use stored procedures (you can use Linq to stored procedures if you wish)
There are numerous debates around this on this site and others. For me, you can normally split the pro Linq camp into guys who have recently come into programming and have not had the history of having to use Stored procedures, ie not been heavily involved in the database side of previous projects.
Form my experience of working on several projects using pure LINQ, stored procedures and a mixture of both these are the two reasons I would stick to Linq for basic CRUD and stored procedures for anything more complex or relying on performance.
1 - Deploymenty/Security - Anyone that has worked in the real world a knows full well that having the database logic separated into stored procedures and not incorporated into the source code and released DLL is a massive advantage. You can add a proper security/access layer around each query using roles and SQL server security, imperative for any serious enterprise level company, and you can also make changes to the SQL of any stored procedure without having to do a new release of the main application (dll). I dont care how good you claim to be we have all had to fix live issues and performance bottlenecks using stored procedures and having to do this with a new application release would have been a nightmare.
2 - Performance/Code Smells - I have seen so many applications littered with huge amount of of badly written and inefficient Linq. Developers get lazy with Linq, little hidden lazy Linq to SQL queries which cause you a nightmare trying to debug performance issues on an enterprise level system - the motto 'get it done as quick as possible' seems prevalent. I have seen more Spaghetti code since the advent of Linq than I had seen with any previous class library/pattern Microsoft have released since COM.
I'm building a new web application project and am confused by the numerous methods of performing data access. I'm backending on SQL and a bit confused whether to use LINQ to SQL or trtaditional ADO.net ?
what are the advantages and disadvantages of using LINQ/SQL over ADO.net?
If it is ADO.net,then what is the best way to retrieve data means either calling the stored procedures or directly calling the t-sql code?
My question is what is cleanes and most effiecient and professional way of creating DAL for webapplication in asp.net?
Thanks
What are the advantages and
disadvantages of using LINQ/SQL over
ADO.net?
Linq2sql generates a series of
classes that are 1-to-1 mappings of
your (selected) database tables - this means you don't have to write tedious and error prone data access code
using ado.net yourself.
Linq2sql may not provide enough value for you if you intend on using a custom object-to-relational mapping (non 1-to-1) - of course you could still use linq2sql, but it would mean having an extra layer in between.
Linq2sql allows you to easily query the database using powerful linq expressions. Writing linq queries provides you with intellisense that you wouldn't get if you embedded your queries as strings inside ado.net commands, or wrote stored procs in management studio.
Using linq, you don't need to know t-sql while you will if you use ado.net (although it can definitely an advantage if your linq queries start doing strange things!). An example of this the complexity of writing t-sql queries that provide paging resultsets simply becomes .Skip(page * size).Take(size).
Linq2sql automatically creates t-sql that uses parameterised queries which is much more secure against sql injection attacks than handwritten ado.net code which builds up a query using a string.
Linq2sql doesn't work very well with stored procedures - you are probably better off not bothering with linq2sql if using sprocs.
Linq2sql could require your database tables to be less-tightly locked down than would be possible writing ado.net code using stored procedures.
If it is ADO.net,then what is the best
way to retrieve data means either
calling the stored procedures or
directly calling the t-sql code?
If you'd ruled out linq2sql, and ado.net happened to the better choice for data retrieval, I would be surprised if you were directly calling t-sql code very often or even at all. I would almost certainly expect you to be using stored procedures for reasons that you have queries that are too complex using linq, and/or security requirements.
My question is what is cleanest and most effiecient and professional way of creating DAL for webapplication in asp.net?
In my opinion, the cleanest DAL would probably use linq2sql as it is the lightest and most targeted ORM for SQL Server (assuming your still interested in SQL Server for this specific question of course).
The most efficient could be the handwritten one using ado.net, but this is probably a waste of time as more often than not, you will find a tool such as linq2sql writing better queries than 90% of developers.
In my opinion, the most professional DAL could be linq2sql, but it is more likely to be the Entity Framework of NHibernate (as other answers have suggested) due to more flexibility.
My last choice DAL in terms of cleanliness and professionalism would definitely be a handwritten ado.net one.
The best way to go is O/RM. Small apps Linq2Sql, larger apps Entity Framework 4 or NHibernate (Fluent NHibernate).
Calling SPs from your code means that your app logic is placed somewhere else than in the app code. It's a way to go but at present less and less popular because of TDD.
The best way is to create DAL into a separated logic layer, own assembly.
I would without doubt go for Linq2Sql.
Download Linqpad and play around with the included samples to get started.
You should check out some ORM frameworks, like NHibernate: http://nhibernate.info
If you want efficient data access in terms of performance than there is nothing faster than pure ADO.NET. You chan check it out here: http://ormbattle.net/.
I'm building asp.net mvc app, and I want to know the ramifications of me switching from sqlserver2008 to mysql?
Apart from some syntax tweaks, what other things should I am taking into consideration (technically speaking ofcourse) if I want to move over to use mysql?
convert sprocs to inline queries
transaction and locking maybe handled differently
others?
There are some differences with how the two treat some kinds of locking and concurrency, etc. but for 95% of web applications those kinds of issues simply never come into play. If you're doing standard CRUD, maybe some transactions, executing a few stored procedures? No difference to speak of except the syntax, a good reference to which can be found here.
I really recommend checking out DbLinq, which is based on LINQ to SQL but supports lots of different SQL databases. It gets us much closer to making applications truly db-agnostic - you can swap out the SQL Server provider for MySQL, PostgreSQL, Oracle, Firebird, SQLite, Ingres - and all the LINQ expressions stay exactly the same. No need to tweak any queries.