Is a good idea use Membership Provider with ASP.NET MVC - asp.net-mvc-3

In ASP.NET MVC we dont have Login controls of webform, then still make sense use Membership Provider? It is a good practice?

Membership Provider is agnostic of Web Forms or any other classes where it will be used, so the least I can say is its not a bad idea.

The Membership Provider is just a data store, use it as you wish. There just happen to be ASP.NET forms controls that also know how to use it.

Yes, it still makes sense. Take a look a the default project created by Visual Studio (not the empty one), to see how it can be used with ASP.NET MVC and unit tests.

Related

MVC5 to use custom membership or my own implemenation?

I'm starting a new project and intending(I actually started implementation) to use MVC 5 and most recent microsoft technologies. In my DB, I have my own table to manage user accounts and storing passwords and I have no problem or complexity doing that.
But(and there always but), most tutorials I see on MVC use .NET Membership. Every tutorial I read to learn about the new fetures is using it. This gives me a feeling that I should too be using it or at least write a custom implementation of it.
Am I looking to it wrongly? Am I missing something here? Do I need to take the development process little bit slower?
I really confused and I'm not sure which path to take specially I'm still at the start of my project.
I would suggest using Asp Identity 2 which replaces the old Asp Membership, with the account functionality scaffolded when you create a new MVC 5 Web application. It gives you heaps of functionality straight out of the box.
Of course, it depends on your requirements, but this is a pretty robust way to get started. It easily allows you to intergrate other OAuth providers like Facebook etc.
Here are some helpful resources:
http://blogs.msdn.com/b/webdev/archive/2013/06/27/introducing-asp-net-identity-membership-system-for-asp-net-applications.aspx
http://blogs.msdn.com/b/webdev/archive/2013/10/16/customizing-profile-information-in-asp-net-identity-in-vs-2013-templates.aspx
http://msdn.microsoft.com/en-us/data/jj200620.aspx
You can map your current user table to the IdentityUser if they follow the same structure.
http://coderdiaries.com/2014/01/29/custom-table-names-for-asp-net-identity/

Overriding ASP.NET Membership in ASP.NET MVC 4

In previous versions of ASP.NET I could modify the Membership Provider settings in web.config to point to my custom implementation.
I'm trying to emulate this in MVC4, but it appears things have changed a little in the template. It appears to be using WebMatrix.WebData.WebSecurity instead of the classic Membership classes. Do I need to strip all that stuff out and replace it with the Membership calls like I previously did, or is there a way to use the new WebMatrix.WebData.WebSecurity classes with my custom Membership implementation?
You will have to strip out all the stuff and replace with membership calls if you want to continue using your custom membership implementation.
SimpleMembership(webmatrix.webdata.websecurity) will not work with existing membership implementations

MVC3 - Is it good practice to use the membership DB that is created on a default web app?

So I'm trying to create an MVC3 web app. I decided to use EF taking care of my database first, instead of using the code first or model first approach.
So, in terms of membership, is it good practice to use the auto-generated ASPNETDB.MDF going forward, and mapping my EF database to it? Or should I scrap it and add membership to my EF database?
The membership system is well known, tested, and functions well. You should use it, unless you have a good reason not to. Even then, you still should use the base IPrincipal and IIdentity functions that Membership and FormsAuth implement.

A good substitute for ASMX web service methods, but not a general handler

The best thing I like about ASP.NET MVC, is that you can directly call a server method (called action), from the client. This is so convenient, and so straightforward, that I really like to implement such a model in ASP.NET WebForms too.
However, in ASP.NET WebForms, to call a server method from the client, you should either use Page Methods, or Web Services, both of which use SOAP as their communication protocol (though JSON can also be used).
There is also another substitution, which is using Generic Handlers. The problem with them however is that, a separate Generic Handler should be written for each server method. In other words, each Generic Handler works like a simple method.
Is there anyway else to imitate MVC model in ASP.NET WebForms?
Please note that I can't change to MVC platform right now, cause the project at our hand is a big project and we don't have required resources and time to change our platform. What we seek, is a simple MVC model implementation for our AJAX calls. A problem that we have with Web Services, is the known problem of SoapException, and we're not interested in creating custom SoapExctensions.
You can mix ASP.NET MVC and ASP.NET Webforms in the same project. You'll just need to add the correct MVC parts to your current Webforms project and have the best of both worlds.
http://www.aspnetmvcninja.com/general/mixing-asp-net-mvc-and-webforms has a good walkthrough of all the steps you'll need to take to get it working.
You can splice your asp.net webforms app with something like Nancy perhaps?
I've had great success with Nancy and Knockout after I abandoned the horrible Ajax Control Toolkit.
(Apologies if I have misunderstood your question - I read it twice)

What's an alternative to MVC?

Seems like every project I'm on uses a Model View Controller architecture, and that's how I roll my own projects. Is there an alternative? How else would one create an application that has persistent storage and a user interface?
MVC has been around for a while. It's a time tested and proven pattern. Many frameworks leverage the MVC Pattern. Martin Fowler has deconstructed the MVC into: Supervising Presenter and Passive View.
Architect Christopher Alexander said it best:
Each pattern describes a problem which
occurs over and over again in our
environment and then describes the
core of the solution to that problem,
in such a way that you can use this
solution a million times over, without
ever doing it the same way twice.
I'm not sure why you would want to move from MVC. Is there a problem you are encountering that MVC does not eloquently solve? To give you a better answer we need to know more about your problem domain.
Things to take into account when considering patterns/architecture: If you are building something with a Myspace type architecture you'll need a robust architecture (MVC). If you are creating a simple crud interface via the web - almost anything will do.
For .Net Web forms (I am assuming web, since you didn't say thick or web client) which is not MVC, it was a nightmare maintaining them. Web Forms applications that lived more that a couple years tended to become big balls of mud. Even then developers discovered ways to use MVC with web forms.
Ironically, the lack of MVC architecture in ASP.NET web forms was one of the driving complaints that lead to the development of ASP.Net MVC framework.
From experience if you don't use some MVCesk approach, your solutions become hard to maintain and bloated. These applications will die a slow painful death.
If your solutions are small one-off projects, the by all means throw something together. Heck there are tools that will generate everything from the screens to the data access layer. Whatever works to get the job done.
Classic CRUD apps built using tools like VB6 and Delphi have user interfaces, persistent storage and don't use MVC. Most of them used data aware controls linked directly to database fields
Couple of links comparing various MV* patterns which might be useful:WPF patterns : MVC, MVP or MVVM or…? & MVC, MVP and MVVM
Look into MVP model view presenter.
User interface is View and an application will always have a model and the bridge between the two is Controller. The whole MVC is nothing special as this is how the things will be always.
At the most you can get rid of Controller and have your view talk to your model but you loose the flexibility.
I've developed an alternative to ASP.NET MVC. You get the same loose coupling and separation of concerns but the difference is in how you go about building your projects.
I have a couple of videos on my blog, source code for the framework, a sample project and a few VS.NET add-ins (New Project item, New Builder and New View).
Builder for ASP.NET
Some key differentiating Features are
1. Templates are just html - no code mixed with templates
2. Templates are thus reusable across views and Web site designers can design templates in their design tool of choice
3. Strongly typed code (no ViewData and stuff) so you get intillisense, compile time checking, F12 navigation etc.
4. You build pages as compositions of views rather than an inside-out approach
5. View can be treated as "real" classes.
6. Everything is complied so no run-time compilation
Quite a few other differentiating factors as well.
In theory :
MVC is a proved technology and yada-yada-yada, and it is ideal for websites.
But in a real case:
A serious project that use MVC required a framework, hence you are following a framework with all their limiting and restrictions. So, at this point, the specific implementation of MVC is rule and not a simple "guideline".
Also MVC fail miserably for websites when it is about to connect to the model other than simple POST/GET, it fail with xml asynchronism and it fail with ajax. (*)
(*) exist some patch but a design must be clear and functional and if you need to "patch it" then it is neither clear nor functional.
Personally i think that the main problem with MVC is that it put so much effort in the Controller, where most project use not more that 5 lines for the controller part.
ps: Most "well done" MVC projects are 3-tier project.
ps2: MVC excluding some framework, is just a buzzterm, IS NOT A SERIOUS TERMINOLOGY and it is reflexed in the group of "interpretation of mvc".

Resources