Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am building a project using ASP.Net 4 and MVC3 using C#.
The ASP.Net Membership Provider is integrated well into the framework.
Role check and some identity information but I have an issue.
It's limited flexibility.
Should I build a new user management system from the ground up and lose the convenient short codes within controllers ect....?
Are there any alternative?
Worry about hashing passwords, caching stuff, session management just gives me a headache when I think about building something from scratch.
I use the ASP Membership mainly for logging-in (only). Then I use database-specific tables for highly-customized user-features that ASP Membership doesn't easily accomodate (or at all). If any custom-feature "can" be (easily) accomodated by the ASP Membership Db...then I use it...but mostly, I put custom user-specific functionality in the target database (in-question).
Also...
Because the ASP Membership functionality can manage many databases at the same time, I run a separate ASP Membership database instance (apart) from those it manages. Doings so has proven clean & friendly for me.
There wouldn't be a lot of advantage in writing your own membership system 'from the ground up'.
You'd be better implementing a custom Membership Provider and Role Provider - meaning that you can easily use the [Authorize] attribute, and other built in membership roles stuff, and then add any extra stuff you need into your custom providers.
Have a look here and here to see what is involved in a MembershipProvider and RoleProvider - just derive from the abstract MembershipProvider and RoleProvider and provide your own implementations
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm a junior full stack and I'm working on a big SPA (for one man) project, as a challenge and demo of what I have learned and I have 3 questions:
Is generally ASP.NET Identity used in companies for medium/big projects or they usually go with custom implementation ?
I wonder if it's worth using ASP.NET Identity for users and roles management or is better to create custom logic for users/roles to I guess learn more and have more control.
If I'll continue developing with identity, will be bad if I use it only for users and roles management, as I saw that it has authentication API too, but I use OAUTH2, setting token was like fast and it's working. So should I try to use Identity as much as I can in authentication too to explain the use of this framework over custom implementation ?
You can answer only to first question because other two are too subjective. Thanks!
As ASP.NET Identity is very customizable, you can take the best from both worlds.
In my company we use custom implementation of IUserStore giving us the flexibility to persist user info the way we wanted. We don't use Entity Framework, for example, which is the default data access used by ASP.NET Identity.
In our case the tables are different and they better match to actual user data for our application (read business objects).
The password hashing/verification process is different also, etc.
You just need to pass an instance of your custom IUserStore to ApplicationUserManager and you are good to go.
My personal opinion is: go with ASP.NET Identity and replace just the parts you need.
EDIT:
You can also implement all of those too
IUserStore<,>
IUserLoginStore<,>
IUserClaimStore<,>
IUserRoleStore<,>
IUserPasswordStore<,>
IUserEmailStore<,>
IUserLockoutStore<,>
IUserTwoFactorStore<,>
IQueryableUserStore<,>
We use it for authentication too. Have in mind that this is tested and will be updated. Is is also well documented and any new devs that are jumping on the project have a greater chance to know what is happening. If you go with a completely custom solution you'll have to maintain that and try to keep it updated with the latest trends/stuff.
Hope this helps to make a better decision.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
All examples I've seen by now for ASP.NET Identity 3.0 use Entity Framework to store user-related data.
Are there any example which does not use Entity Framework and where ApplicationUser class is not derived from Microsoft.AspNet.Identity.EntityFramework.IdentityUser?
In ASP.NET Identity 2.x it was needed to implement IUser interface. It seems there is not such interface now - so we're not sure how to define User class correctly. There is almost no documentation on this subject.
Second problem is with AddIdentity call in Startup.ConfigureServices. It's pretty tied to the particular classes from Microsoft.AspNet.Identity.EntityFramework namespace and it's unclear how to register identity services without those classes.
I have implemented it in my project, the main things you have to implement is UserStore and RoleStore
my SiteUser and SiteRole classes do not inherit from anything
the main thing is to add your own services before letting asp.net identity add its own services
services.TryAdd(ServiceDescriptor.Scoped<IUserStore<SiteUser>, UserStore<SiteUser>>());
services.TryAdd(ServiceDescriptor.Scoped<IUserPasswordStore<SiteUser>, UserStore<SiteUser>>());
services.TryAdd(ServiceDescriptor.Scoped<IUserEmailStore<SiteUser>, UserStore<SiteUser>>());
services.TryAdd(ServiceDescriptor.Scoped<IUserLoginStore<SiteUser>, UserStore<SiteUser>>());
services.TryAdd(ServiceDescriptor.Scoped<IUserRoleStore<SiteUser>, UserStore<SiteUser>>());
services.TryAdd(ServiceDescriptor.Scoped<IUserClaimStore<SiteUser>, UserStore<SiteUser>>());
services.TryAdd(ServiceDescriptor.Scoped<IUserPhoneNumberStore<SiteUser>, UserStore<SiteUser>>());
services.TryAdd(ServiceDescriptor.Scoped<IUserLockoutStore<SiteUser>, UserStore<SiteUser>>());
services.TryAdd(ServiceDescriptor.Scoped<IUserTwoFactorStore<SiteUser>, UserStore<SiteUser>>());
services.TryAdd(ServiceDescriptor.Scoped<IRoleStore<SiteRole>, RoleStore<SiteRole>>());
some of the same interfsaces will be registered here but it will use yours if they are registered first
services.AddIdentity<SiteUser, SiteRole>();
Are there any example which does not use EntityFramework and where ApplicationUser class is not derived from Microsoft.AspNet.Identity.EntityFramework.IdentityUser?
Since ASP.NET Identity 3 is part of the .NET Framework 5, which is still unreleased, my guess is you won't find any examples.
In ASP.NET Identity 2.x it was needed to implement IUser interface. It seems there is not such interface now - so we're not sure how to define "User" class correctly.There is almost no documentation on this subject.
Again, the lack of docs is probably due to the unreleased nature of the software. However just looking at the source code, it seems as though the ApplicationUser can derive from any POCO object -- without the need to implement an IUser<TKey> interface.
As far as configuring services, have a look at IdentityServiceCollectionExtensions and IdentityEntityFrameworkBuilderExtensions. It seems as if the first is in identity core as a means of providing a context within which to register services for application identity, whereas the second is an entityframework-specific implementation using that context.
The solution for implementing something that uses ASP.NET Identity 3 but not EF seems like it would just be a matter of providing different implementations for the identity service interfaces and then wiring up those dependencies during app configuration. You can use the base EntityFramework implementation as a guide for how to DIY. But caveat emptor, identity 3 could change again before final release, so anything you build against identity 3 now is subject to change.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I am having 3 years of experience in asp.net. I need to list down topics that are related to web development
I have listed the following topics. Please add your topics if in case i have missed
A.OOPS
Classes
Objects
Polymorphism
Encapsulation
Abstraction
Inheritance
Interface
Abstract class / virtual cass
Access Modifiers
Overloading vs Overriding
B. C#
Boxing-Unboxing
Delegate- event
Collections
Generics
Value Type vs Reference Type
C. ASP.NET Topics
Authentication and Authorization
state Management
XML/XSL/XSLT
Web Services
Array List, Hashtable, Generices
Themes, Skins and Master Pages
Remoting
Reflection
Serialization
Caching
Threading
Localization
HTTP Handlers / HTTP Module
ASP.NET Entity f/w
JSON
D. Designing
HTML
CSS
XTML (Also Themes, skins and master pages)
E. Advanced ASP.NET Concepts
WCF
WPF
JQUERY
Silverlight
AJAX
DNN
Axure
MVC
F. ADO.NET
H. SQL Server
Normalization
SP/ Functions (differnce), views
Triggers
PLEASE POST THE TOPICS THAT I HAVE MISSED OUT
Looks like a good list, but worth knowing about the following too I reckon
LINQ
O/R Mapping - eg Nhibernate
Dependency Injection / Inversion of Control - eg. Windsor / structureMap
Design patterns - eg MVC MVP SOA etc
SQL Full-text search
SQL 2008 new features- eg CTEs
New features in asp.net / C# 4.0
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In response to an answer posted by Marc Gravell and his suggestion via email, I was wondering:
What choices do people make when deciding on their architecture for a new project?
This question could serve as a decent reference point for links/ideas/suggestions/architecture decisions, anything really that is of interest when deciding the best way to approach a new solution.
I am currently working on an ASP.NET MVC application - mainly as a exercise to increase my experience of the new framework - that works with an ExtJs front end passing Json objects between the layers.
Testability is very important so my .NET layer uses interfaces to define contracts and consists of a service layer, which handles data validation and application logic, which in turn interacts with a repository layer that just handles the data persistence and retrieval. All allowing me to test quite thoroughly.
I have a custom model hierarchy that is based on the database, however, it is not related to any ORM (I am using LinqToSql at present) tool tying it to a particular platform. My repositories return my custom models and not their own database structures, which will hopefully allow me to develop different repository implementations in the future without too many problems.
Another reason for this approach was that I am working with a legacy database that has some interesting design choices and cannot change the structure too much at present, so I wanted a bit more control over the resultant models.
All this may seem completely wrong to some of you so tell me what you think ;)
It sounds like you are on the right track. Personally, in the current incarnations, I would always choose MVC over web forms. Web forms abstracts too much from the underlying model and I find it is usually more trouble than it is worth. Only if you can safely predict that you can stick tight to the model web forms was designed to handle, work within the out-of-the-box pattern, and do not care much about testability, would I recommend web forms.
The only other scenario where web forms might make sense is if you have a team of people highly ingrained with this technology and want to keep inline with existing application stacks. Even then, for the growth of your developers and long-term product maintenance (post transition), I still recommend MVC if you can swing it.
That said, Microsoft will probably continue to support the web forms model for some time and eventually the two models will probably become easier and easier to plug and play or interchange with one another (based on conversations I have had with a couple of the ASP.NET team's program managers).
while enticing at first, for me, webforms become difficult to manage as the application grows. with mvc, relationships are more natural and consistent with ideals.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I was just assigned to do a CMS using ASP.net 3.5 and MySQL. I am kind of new to ASP.NET development (quite sufficient with C#) and I am wondering what major ASP.NET and general .NET features I am losing when I don't have the option to use Microsoft SQL Server.
I know already from quick Googling that I lose LINQ (and I was really looking forward to using this to build my model layer!), but I am not sure what other handy features I will lose. Since I've been relying on ASP.net tutorials which assume that you use MS SQL Server, I feel a chunk of my ASP.net knowledge just become invalid.
Thanks!
You can leverage MySql in a number of ORMs, one of which is NHibernate. For the most part you can treat it as if you were running on SQL Server or Oracle. And with Linq2NHibernate, you can get nice LINQ syntax.
You'd lose the SqlDataSource control, but some would argue that it would actually be a blessing :)
And of course you'd lose Linq2SQL. EntityFramework will have 3rd party adapters MySql, Oracle and a few others soon after release.
You do not lose LINQ, you lose LINQtoSQL. LINQ itself is more generic as it can be used on anything that implements iQueryable.
You lose the SqlDataSource, not a big deal.
You lose some of the integration the server explorer does for you with sql server, again not a big deal.
As far as im concerned you dont lose anything very important, and you shouldnt be losing any of your .net knowledge. Most examples use sql server as a default but they can easily be changed to use another database.
Also there are a few open source .net CMS packages out there already that use MySql take a look at cuyahoga
As a consequence of losing notification services, you also lose SqlCacheDependency
Some things that come to mind:
asp.net has nice "automatic" user management (authentication) system. I think it only goes with SQL Server, but there might be a way to make it work on other DBs. The tutorials assume SQL Server usually (or the built in file based DB for development)
Not related to asp.net, but useful for any project is SQLCLR, which I find a great addition to sql server. Lets you delegate logic you write in the business level (supporting dll or classes) to sql server in the from of a SP, but the SP is written in vb.net/c#
Notification services