I'm starting work on a Custom Membership provider and I was wondering which option would be the best to develop this application in Linq or Entity Framework?
Also I have a need to link two table from different database via a common ID and I was wondering does anyone know of any good tutorials about creating a MVC 3 Web Application that uses either Linq or Entity Framework to do this.
From my research Entity Framework seems to be the best method suited to my situation but I would appreciate some advice / confirmation that this correct and a little direction to a tutorial is possible?
By Linq, you mean Linq to SQL vs. Entity framework? If so, then I would recommend using Entity Framework. Microsoft's development on Linq to SQL has virtually stopped so EF has a better future.
NerdDinner is one of the more popular tutorial applications that uses ASP MVC 2 and entity framework. ASP MVC 2 is similar enough to get started with the basic concepts. Here is a good walk through tutorial:
http://nerddinnerbook.s3.amazonaws.com/Intro.htm
The code itself is freely available:
http://nerddinner.codeplex.com/
Related
I have been checking resources to implement authentication in my web forms application built with entity framework. All examples I found are MVC-related. I have used regular Asp.Net Membership framework a long time before I began to use EF. However, I could not find Membership implementation with Entity Framework code-first. I did implement the Claims-Based Identity (EF created the tables for me in DB) but I do not know how to utilize it in the application (like login), and it looks more complicated to me. Can anyone guide me ?
There are a couple of good tutorials on the asp.net web site:
http://www.asp.net/identity/overview/getting-started/adding-aspnet-identity-to-an-empty-or-existing-web-forms-project
http://www.asp.net/web-forms/overview/getting-started/getting-started-with-aspnet-45-web-forms/membership-and-administration
Soon i will be starting to work on a small to medium web project. I will be the only developer to work on this project. So i am looking for pointers towards some design decisions/tools/technology. I would like to use asp.net MVC for this web project (the reason being this project has got good chance to grow a lot, therefore thinking more maintainable).
We use oracle as our backend and configured enterprise application data access block to use with odp.net and seems to have worked well. But all of our previous projects were typically asp.net web forms/windows forms.
So with mvc, is it better to use ORM like nhibernate than DAAB?
I have gone through this article, but still confused.. Thanks
I'm creating a web app using ASP.NET MVC 3 and Entity Framework 4.1 code-first. I'm designing the project via Repository Design Pattern. I know how to implement RDP and Generic RDP. But my question is that using StructureMap is a good idea on this case? Thanks to any idea and help.
Well yes, but structuremap is more related, imo, to the DI approach you will use than the Domain specific approach you will implement.
I personally use AutoFac, but Structuremap is a also very good, you may want to consider also Ninject. All of them are really powerful and have a nice syntax to work with imo.
I am going to start new MVC 3.0 .NET 4.0 application.
I want to implement each component for my web site once and simply reuse it then for another web sites i going to build.
Currently i am looking the best practice i can use to achieve my goal.
I did some research and found that I may get a lot of advantages using MEF.
I found interesting MEF MVC solution called plugable MVC http://www.thegecko.org/index.php/2010/06/pluggable-mvc-2-0-using-mef-and-strongly-typed-views.
Is it really worth to use such kind of approach(Plugabble MVC) of building MVC apps?
Advantages disadvantages of pluggable MVC?
May be somebody may suggest something else?
What specific problem are you trying to solve? MVC is a very extensible and pluggable framework as it is. I would say that for a simple site MEF is not necessary. Please provide more information on the issues you are running into with the stock MVC framework.
I have used the Entity Framework to start a fairly simple sample project. In the project, I have created a new Entity Data Model from a SQL Server 2000 database. I am able to query the data using LINQ to Entities and display values on the screen.
I have an Oracle database with an extremely similar schema (I am trying to be exact but I do not know all the details of Oracle). I would like my project to be able to run on both the SQL Server and Oracle data stores with minimal effort. I was hoping that I could simply change the configuration string of my Entity Data Model and the Entity Framework would take care of the rest. However, it appears that will not work at seamlessly as I thought.
Has anyone done what I am trying to do? Again, I am trying to write an application that can query (and update) data from a SQL Server or Oracle database with minimal effort using the Entity Framework. The secondary goal is to not have to re-compile the application when switching back and forth between data stores. If I have to "Update Model from Database" that might be ok because I wouldn't have to recompile, but I'd prefer not to have to go this route. Does anyone know of any steps that might be necessary?
What is generally understood under the term "Persistence Ignorance" is that your entity classes are not being flooded with framework dependencies (important for N-tier scenarios). This is not the case right now, as entity classes must implement certain EF interfaces ("IPOCO"), as opposed to plain old CLR objects. As another poster has mentioned, there is a solution called Persistence Ignorance (POCO) Adapter for Entity Framework V1 for that, and EF V2 will support POCO out of the box.
But I think what you really had in mind was database independence. With one big configuration XML that includes storage model, conceptual model and the mapping between those two from which a typed ObjectContext will be generated at designtime, I also find it hard to image how to transparently support two databases.
What probably looks more promising is applying a database-independent ADO.NET provider like the one from DataDirect. DataDirect has also announced EF support for Q3/2008.
http://blogs.msdn.com/jkowalski/archive/2008/09/09/persistence-ignorance-poco-adapter-for-entity-framework-v1.aspx
The main problem is that the entity framework was not designed with persistence ignorance in mind. I would honestly look at using something other than entity framework.