I am quite new to entity frame work 4.0 and what I know from my intial analysis is entity framework is nothing but an abstraction of ado.net with its storage model, conceptual schema and the mappping between these two.But one thing I am unclear is while fetching data from database or executing any stored procedure what mechanism its following.
Is it adopting the traditional ado.net approach or is it the concept of linq2sql?
The reason I am asking this question is in our project we are not suppose to use linq for some security reason (I am not sure what this security linkage is but we have not to follow linq relegiously).
So I just wanted to know how entityframework works for performing all its db transaction and whether by any chance it is using linq to sql?
Hope I was able to convey my problem. Please look into this and respond ASAP. I am in a kind of fix :(
Regards
Subrat
No - both Linq-to-SQL and Entity Framework make good use of the LINQ features in C#/VB.NET - but they're both totally separate projects.
Linq-to-SQL was created by the C# team, more or less as a "proof-of-concept" for how to use LINQ with databases.
Entity Framework on the other hand grew out of the database teams (ADO.NET team) at Microsoft and was designed from the ground up as a full-fledged, enterprise-ready system to be the "next big thing" after straight up ADO.NET
Why using LINQ (as a technology) should have any security implications is beyond me.....
Yes - with the Linq-to-SQL approach, your application needs direct access to all underlying tables - read and write. But with EF in version 4, you can do very safe styles of work:
SELECT only from views exposed in the database
handle all the CUD operations (INSERT, UPDATE, DELETE) by wiring up your EF entities to stored procedures
With this, your applications don't need direct table read/write access at all - no different than when manually using SELECT from views and stored procedures for all other operations.
Related
This is not really related to Programming But I do need a answer for that if anyone know.
What are the ADO.net Data access strategies for MVC application. choices are
1-DataAdapter
2-Datareader
3-EntityFramework
5-LinqtoSQL
I know that there is a DataReader that provides stream of data from the data source and DataAdapter provides the bridge between the DataSet object and the data source but not sure if that is call Data access strategy, I know Linq to SQL and EntityFramework are the Strategies. Please help
Data Access Technology
SQL data access options available in .NET framework are; Entity Framework, LINQ to SQL and SQL client.
Solution
SQL client
SQL client requires writing custom queries or stored procedures for each data access operations and extra code work to convert them into .NET objects. This technique will be beneficial when complex and dynamic queries are used very often. SQL client provides the best performance of these three technologies but requires maximum development and maintenance effort.
LINQ to SQL
LINQ to SQL provides a simple mechanism to access SQL database and keeps development effort to minimum, but not suitable for complex data structure. Query performance generally will be slower compared to SQL client.
Entity Framework
Entity Framework provides a balance between LINQ to SQL and SQL client. It supports complex data mappings and by implementing proper Repository pattern, we can abstract the storage mechanism from business layer easily.
Selected Approach
Based on the above observations (in particular: support for complex data mappings; and simpler implementation) the proposed solution is to use Entity Framework for data access.
Note: The above description was written few years ago and may not be up-to-date. Thought it might help.
System.Data classes are need to detailed management data storage of your app. System.Data.Entity or Linq to SQL its more simply to using in small projects.
I have an application that I want to migrate to ASP.NET MVC. There are few stumbling blocks that I am not able to clear.
I am using the following components
Linq to Entities
MVC with Razor
Now I have three major hurdles.
The sql query is quite complex - I want to use it as it is (without Linq )
How to create a view that will display data from this query's resultset
the query involves joins on tables across multiple databases (though on the same server ) - what is the best approach to make it pure-linq in future.
I'm still learning the Entity Framework myself, but hopefully my answer will help you out a little with some advice and starting points.
If you have a complex sql query that you want to leave intact as is, your best bet is to add it as a Stored Procedure in your Database. You could then add/call the Stored Procedure using the Entity Framework. You can set up the model to use a stored procedure.
Using my suggestion in #1, I'd recommend you simply build a custom object to store the data in the structure you need it to be in. In your controller (or however you have your project set up for data/business logic) you can populate the object by using EF to call the Stored Procedure. You could then create your view and strongly type it against that object/model and display it in whatever manner it's needed in.
As for this question, I am not sure. However, I did do a quick search and hopefully this thread may help point you in a direction. EF4 cross database relationships
Having used all of them (some more than others), I am still undecided on which could be the best to use (with .NET 3.5). What are the pro's and con's of each when developing?
SubSonic 3
Not enough samples/documentation (I know its a wiki and people can update it, but it can be tricky to track things down - e.g. where are the sample apps (WebForms, MVC (current version, rather than pre-3), WinForms)). Text Templates didn't work as expected when I first tried them. For example, it does not clean up the table names like SubSonic 2 did (removing/replacing spaces for example). Also, you cannot say which tables to include, just the ones you can exclude (in ActiveRecord.tt). Context.tt and Structs.tt generates code for all the tables (you would probably not want the 'aspnet_' ones, and probably some others (session tables) as well).
Saying that though (hope I'm not being too harsh), it is quite a good ORM to use, minor issues aside.
Entity Data Model (Entity Framework)
Visual Designer for setting up models. Syncs with database, might be considered a bit 'verbose' and hard to understand. There is fairly decent documentation though. Not gone that much further in depth though.
LINQ to SQL
Also has a designer for creating models. Simple to use. Less features than the other two. I also had to apply a hotfix for an obscure bug (wouldn't update when the model had foreign keys that were not of type int)
NHibernate
Looked at this in the past, but not that easy to set up compared to the above.
Any sample ASP.NET MVC apps using this?
Ideally I would want a framework that:
a) could generate the models from a database
b) support LINQ syntax
c) retrieve only the data that is needed (e.g. for paging)
d) allow data annotations
e) could generate the sql to update or create new tables in an existing database
MVC is presentation layer, ORM is Data layer
I don't think that ORM has anything so much to do with an MVC application. At least if you tier your application properly. Model in an MVC application is rather model of the presentation layer view. A view model through which controller and view communicate. Not necessarily data model. MVC project template is a bit confusing, since developers think that MVC model = data model. In any business application that is not completely trivial (like a single assembly simple application) this is not equal. And it's better that its not. Especially if we take into cosideration separation of concerns. We shouldn't rely on particular ORM classes in any layer other than data layer.
But if you intend to use DTOs in your MVC application (as view models) I suggest you use that ORM that creates partial classes, so you can easily add additional stuff on them (like attributes). Your data annotations can be written inside of a special metadata class that can be attached to your model class by a single class-level attribute.
Suggestion
But I suggest doing something else. Use a separate layer with POCOs that will be used on all layers and would have data annotations on them. This will make your presentation layer independent of data layer and your POCOs may also be presentation optimised (like having a class called UserRegistration for instance with two password properties - with repeated value as well). Your repository in your data layer would be responsible for POCO conversion so all layers will exchange data using POCOs only instead of using data objects.
ORMs and class generation
With Entity Framework you do get a very controllable environment to generate your classes from a data store schema. Unfortunately it's not the same with others. Generateion is not all-in, but can be controlled and manipulated manually as well (if you'd like to do TPH/TPT structures).
Similar with LINQ to SQL. I haven't used any other ORM but I guess LinqConnect may have it's own editor similar to EF Visual Studio editor, because I've been working with MySql connector from the same company and I've used their designer for entities because it was better than the one provided with Visual Studio 2008.
But you have tools that provide code generation (and you can get templates on the internet for various ORMs as well):
there's T4 built into Visual Studio that can generate code for you; You can as well fint templates for ORMs written in T4 that you can then easily customize. Or write your own acording to your needs (I've written enumeration generator from DB lookup tables in the past)
MyGeneration is open source and you can find lots of templates for it
CodeSmith is not free but is a proved product that I've used in the past with .netTiers template (before we had LINQ) which saved lots of time and worked perfectly
We're about to embark on some ASP.NET MVC development and have been using our own entity framework for years. However we need to support more than our entity framework is capable of and so I'd like to get some opinions about using MVC with a more robust framework. We have narrowed down or choices to either NHibernate (with the Fluent APIs) or LINQ to SQL.
Which framework lends itself best to MVC style development (I know SO uses LINQ to SQL)?
If we want to support SQL Server, Oracle, MySQL - does that exclude LINQ to SQL?
As someone who has just switched from LINQ to SQL to (Fluent) NHibernate, here are a few things I've noticed.
LINQ to SQL took so long to figure out how to do the equivalent of a join-subclass. After many modifications, I read somewhere that it is not possible. It can only map inheritance if ALL the columns are in that same table. This is great if there are a few columns, but there are tons in my case and sub classes are parents to other sub classes and so on. Why should I put them all in one table for the sake of my ORM?
NHibernate from experience has been robust (sometimes too much for small quick projects) and although familiar with it through small projects, I felt it might be too much and went the route of LINQ to SQL since I could generate a DBML file and be going within minutes.
Fluent NHibernate. Takes the best of both worlds (in my case). I can map the way I want to and have my database the way I want and not have to compromise in my domain or data models. Also one word: Automapping... icing on the cake.
I would have had to go with another ORM once I found limitations and hit a few road bumps with LINQ to SQL, but Fluent NHibernate made this choice easy, and I don't think I'll leave it unless something comes around that does the job even better.
So, like Rob Scott said, the question is how are you abstracting you domain => data model? And are you starting with a domain or a database? How complex are the relationships? If you have any inheritance at all I'd say just go with a richer ORM framework and save yourself the grief.
Fluent NHibernate has some of the best documentation I've ever found and there are so much support, notes, blogs and resources it's self-hate to do anything less... IMO! I was up and running in less than 24 hours.
Oh and if your'e new to NHibernate pick up the NHibernate in Action book to help grease the wheels although there is a lot of help for that framework as well.
The best indication that a tool isn't working is when you have to WORK the tool... LINQ to SQL I was customizing, reading white papers, all sorts of madness and it refused to generate appropriate queries, right when I was tempted to modify my table and domain, I said let me give Fluent a whirl, and I'm happy I did.
Good luck to you.. Sorry for the long response; this has all been in the past five or so days, so I guess I'm still caught up :-)
I've had great success using Fluent NHibernate and dependency injection (Ninject, in my case) with MVC.
It seems to me though that any mature ORM should work well with MVC. Since the nature of MVC (Model/View/Controller) separates the three concerns, any ORM should fit quite nicely into the "Model" role.
LINQ to SQL is for SQL Server. Entity Framework supports some other databases as well.
NHibernate is good choice. You may use Castle ActiveRecord (it's built on top of NH) if you are doing data based application or Sharp Architecture for project guidance.
Entity Framework integrates nicely with MVC and supports other databases.
The short (and not so helpful) answer is that both of the ORMs you've mentioned will work with MVC. A longer answer is that you should think about how you want to work with your model objects. For example, do you want to do domain object first development (ala a Domain Driven Design approach), or are you implementing a "forms over data" type application where you might want to generate a data access layer from an existing db? What is your preference for specifying mappings? Do you want to use a fluent interface or are you happy with mapping files (or attributes on your domain objects)?
These are the type of questions you need to investigate when choosing an ORM -- and they're mostly independent of whether you're using MVC or Winforms.
Entity Framework makes things complex. Use Fluent NHibernate, with Repository pattern and inversion of control in controllers.
NHibernate will make lots of things easier. We have recently migrated from Entity Framework to Fluent Nhibernate, and Fluent NHibernate is definitely the better candidate.
I am starting out on a project that will involve ASP.NET MVC using a legacy ODBC 2.0 compliant database. The goal is to replace current system functionality with a web front end over a period of maybe a year then swap out the backend with SQL Server.
The plan would be to code against SQL server then insert some shim into the repository classes to use ODBC instead. Is it even feasible to do this ? Entity Framework doesn't have built in support for ODBC.
Any thoughts or advice would be appreciated.
I personally use NHibernate with MVC. Originally I picked it up because our database doesn't support EF but enjoy it enough that even if we moved to SQL Server I'd keep NHibernate.
The learning curve is kinda weird. It is definitely steep to become an expert, but it is interesting in that it is pretty organic to let it handle more and more of the work for you as you get comfortable with certain layers.
So for your case NHibernate probably supports your database, can be used as a simple data access layer (just returning DTOs), provides a database agnostic interface and can support SQL Server when the time comes. If you end up wanting more out of NHibernate it is there when the time comes.
There's nothing to stop you writing your own data access layer, to query the ODBC Database. You could also make your own entity layer so that the MVC model can populate your entities using the data layer, and return these objects to the controller.
Basically, have a data access and entities layer under your mvc app, then you can replace these entities, with entity framework, or nhibernate entities, at a later date.
This way of doing it means that your MVC app doesn't need to know what database it is using, it also means that you should have an easy time when you switch an entity later.