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.
Related
I am saving a complex object graph from breeze, and I get the following error from the server:
Error: CROSS APPLY is not supported by Oracle
We are using an Oracle database using Devart provider. From my research, it seems that the only solution to this problem is to avoid certain linq query expressions. These threads provide further context:
http://forums.devart.com/viewtopic.php?t=18849
http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/ae826dd9-1bab-4f64-a7ee-f082a2177346/
The last thread linked is particularly disheartening, as this appears to be a Microsoft-related EF issue on which they have gone dark on for quite some time.
Since the only remedy for this appears to be avoiding specific linq operators/expressions, I must ask if there is any way to use breeze and avoid these offending linq expressions? If not, I am lead to conclude that breeze is currently limited only to relational databases that are fully-supported by EF, which from the my research is effectively only MS SQL.
Hoping I am wrong,
Mathias
If you want to use Breeze's EFContextProvider then you are limited to using an EF backend. However you do some other options. The first is that you can pass your own parameters into your controller methods, ( see the EntityQuery.withParameters method). This may allow you to rewrite your expression on the server to avoid EF expressions that cannot be tranlated properly for Oracle.
In addition, you can use Breeze with your own custom context provider or you can take over the server side completely. The first is a good approach if you are talking to another .NET backend, the second is appropriate when you are talking to an arbitrary non .NET backend.
We are planning on releasing an NHibernate backend to breeze as well as a Node-MongoDb backend within the next few weeks to illustrate both of these.
Is it possible to use LINQ and ADO.NET Entity Data Model together in a project? I have a project built on ADO.NET Entity Data Model from a previous user and has .edmx file, but I am used to hard coding everything, opening connections via ADO.NET.
Is there problems using both together in an MVC project?
LINQ(Language Integrated Query) is TSQL in C# (yes we can query xml, lamda expression etc its lot more but mostly used for TSQL...) you can write LINQ queries against LINQ to SQL (.dbml) OR Entity Framework (.edmx) by creating the Context of each there is a bit of diff in calling methods like in EF Object.AddToObject(o) and in LINQ to SQL Object.InsertOnSubmit(o) and .Savechanges()/Submitchanges()
LINQ to SQL supports only MS SQL server but EF can support other databases as well i.e. MY SQL etc
and if you are using any of these in your project you can still use old Ado.net anywhere in your project by providing proper info to methods or call stored procedures by passing parameters after opening connection like we did in old days......
Linq is simply a way of writing your sql in C#. Well it's lot more than that really. But in this context whereever you would put some sql, you use linq intead so it's agnostic as far as EF is concerned. Or any other framework for that matter.
The real bonus is with a bit of thought you can use something other than a sql database for your persistence.
There are 2 sorts of Linq
Linq To Objects and Linq to SQL
Linq to SQL wont work on your ADO Model as that requires a Direct link to the SQL
but Linq to objects will work on the ADO models objects just as easily as any other
in real terms all this means is that instead of managing the construction for the query's in the DB Linq will let ADO handle it, you wouldn't see any difference
I'm a newbie to ASP.NET MVC. I've been learning MVC 3 for the past couple months and at my job I have to design a CRM system using MVC 3.
In all MVC 3 tutorials, they use MS SQL Compact Edition.
In the CRM project, I have to import Products table from the QB Database and populate that into the CRM.
Keeping in mind, the CRM has to use the QB database and import the products table and
Should I save the CRM data in SQL CE or should I use SQL Server to save all the CRM data as well as the QB data?
MVC 3 is entirely decoupled from the data layer.. The reason you'll have seen most tutorials coupling it with SQL Compact is because most web application tend to need a database of some sorts to be functional and SQL Compact is one of the simplest options when focus should really be on MVC itself.
As far as MVC, you need some way of making data available to the controller and ultimately the view.. you don't even have to use the entity framework (which I guess most examples use for simplicity), however, if you do want to use the entity framework, it looks like you can query quickbooks directly by using this
As I understand, you should implement next logic:
Retrieve needed data from QuickBooks. Here you can use any kind of paid tools like RssBus QuickBooks Data Provider mentioned above, but you are still free to do it using QuickBooks SDK directly (QBXML or QBFC), it is not so hard.
Convert received data to format applicable to your Products table structure.
Perform data export using LINQ to SQL or whatever you want. It is completely up to you which edition of MS SQL Server to use and depends only on complexity of functionality that you need from it.
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.
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.