I want to create a Rich Internet Application in Silverlight. One of the requirements is that the back-end of the application should work with different database providers (SQLServer, PostgreSQL, Oracle).
I'm planning to use Entity Data Model to represent database objects and Domain Services to expose these objects to the client.
The problem is that I don't have a clue if the same data model can be used with different database providers and how sophisticated that would be to change the provider without recreating all the model.
I want the application to be reusable on different environments, so that i can import the same database schema to any existing database, change the provider in the ASP.NET web application and that's it.
Is it doable? Or maybe there are other ways to achieve similar functionality? Thanks in advance for any suggestions.
I would like advising you to look through existing Entity Framework Best Practices
Related
I've been Googling terms like
configure database for mvc authentication
But I can't find anything from this decade that relates to my configuration.
I've created an MVC application using .NET Framework 4.6 with authentication support (database first). Now where do I find step-by-step instructions for creating the database tables and configuring MVC to use them?
Thanks for any tips!
The correct thing to google for is 'ASP.NET Identity'.
If you generate an MVC app straight from one of the templates it will generate a number of classes to handle security and identity.
One of these classes will implement interface IUserStore. The class provided will inherit from Microsoft.AspNet.Identity.EntityFramework.UserStore<TUser>, and uses Entity Framework to check the database if the tables exist, and create them if they are not there.
If you are uneasy about giving your application enough privileges to modify your data schema (ew!), you can create your own class that implements IUserStore and plug that into the system.
It's a big topic, but hopefully this is enough to get started with.
I am writing a new web site and am looking at Asp.Net Identity 2.0. Out of the box, it uses Entity Framework for all of its data access. For the rest of the site, we were creating middleware web services for data access. Our original plan for security sake was that the web servers would talk to middleware and middleware would talk to the database via Entity Framework. We had planned on blocking via firewall database access from the web server.
I see that I can create a custom provider for Identity 2.0 and it in turn could use middleware for it's data access.
Here are my questions:
Is it more secure to not allow the web servers to have direct database access?
If it is more secure, why would Microsoft not build it that way out of the box
If you were starting from scratch like we are, would you recommend using entity framework or writing a custom provider that goes through our middleware layer?
Thanks.
1.) It can be secure. I don't see it as a security issue but coupling issue. What if you want to upgrade or change from Entity Framework in the future? What if you want to change from Identity 2.0? What if you want to upgrade one but you can't because the other doesn't support it yet.
2.) Microsoft wanted to promote it products first and foremost. For simplicity sake if your ok with Entity Framework and Identity 2.0 and don't mind how coupled they are it could be perfectly fine solution.
3.) How much time/effort can you afford to spend on the custom provider? It might not be worth the effort to create your own provider.
Asp.NET Identity out-of-the-box is actually Asp.Net Identity on Entity Framework. It generates a database, connection string, the model files, the controllers and a context class for you, which you can redirect to your own database for it to generate the Identity tables within. Everything is very secure, and they've taken care of a lot of the authentication/password hashing for you. I wouldn't say it is worth it to create your own provider, but you can also create your own provider within Identity if you want. Identity 2.0 is great. Very easy to add custom table properties, etc.
I am building an MVC3 web app and new to .NET and programming in general.
I was thinking about using the built-in ASP.NET membership provider but it seems I would have to tip toe around it, unable to cleanly link users into the rest of my entity objects and it would be a separate database too.
I just need the basics Users, Roles, Password change/retrieval. The addresses and other user specific info I take it don't have anything to do with the membership provider tables ? As in I would just need a FK relationship with the UserID etc. in one of the respective membership tables?
From what I have been reading there are ways to inherit from ASP.NET Membership Provider and implement the abstract methods for use wit EF. If that is my best bet are there any good examples or tutorials on doing so?
Rolling my own would be quite difficult I suppose, but if there's a good guide on doing so with EF codefirst I'd gladly check it out. Or maybe there's already some recommended providers on codeplex?
PS. Using sql express and will be deploying to some cheapo webhost, prolly with 1x SQL server 2008 db limit.
Thanks..
You should look at MVC3 Boilerplate project on GitHub. It has EF integration with MembershipProvider, look specifically at the UserMembershipProvider classes.
Very new to membership provider and just implemented on my new web site. I thought it would be nice to be able to use LINQ to query the database. Can I implement LINQ to SQL on that database?
You shouldn't really be querying the database directly. There is a Membership API for that. It uses a pattern called the provider model which means that you can use the same API always and then swap out a different membership provider without having to change your site code.
You might want to do this to use an xml file, or a webservice, or an in-memory provider, but you should still be able to use the Membership API without having to worry about how the data is being retrieved.
If you do want to write some linq-to-sql code then you should write your own membershipprovider:
http://www.google.co.uk/search?q=asp.net+custom+membership+provider
BTW, If you are just getting started then you should be learning Entity Framework really because Linq-to-Sql has been kind of superseded by EF.
All the things rtpHarry said are right, generally you would use the membership API whenever you are within your ASP.Net application.
However, if you are querying your membership DB from another application for some reason, for example if you had a WinForms admin application or something, then you certainly can use Linq to SQL (or Entity Framework).
I want to know list of advantages of using Entity framework over data access layer.
My website is host in shared hosting and i don't have access to IIS
Considering that i am working shared hosting world, is it feasible to work with entity framework?
Microsoft has publicly stated that Entity Framework will be the preffered data access technology for the .NET platform. Given your experience I feel like Entity Framework would be a huge asset to your ability to rapidly develop applications. Shared hosting is completely irrelevant to the fact that you are using entity framework. Just make sure that the hosting company supports .Net 4 framework (or w/e framework version you work with).
Entity Framework is a data access layer. Specifically it's an Object Relational Mapper.
So it basically comes down to - do you want to write your own DAL? - or would you rather spend your time building out the Data Model, and then having Entity create your entities and classes, etc.. for you.