I have a MVC web application that I am using my own membership provider. I have implemented the Entity Framework with POCO’s, repositories, and a unit of work to both the MVC app and the Custom Membership Provider.
I am finding that when the data changes outside of the entity created in the membership provider, the data is not updated. The system works fine when the entities are short lived in a web request, but the membership provider is started with the web application and is not disposed like a controller.
I have read every post I could find and have not found how to overcome this limitation of Entity Framework. Do I have to resort to the old ADO code to get the latest data from the database?
Make sure you have overrided WebSecurity and other Microsoft Membership Provider classes at the right way. For Security reasons and the Architecture of Entity Framework, may not happen appropriate coordination among those. A good example for implementing sample membership provider with Entity Framework and Asp.net Membership provider can be found at The nuget gallery. I wish to be useful for you.
Related
I am starting to work on a new project so working on laying on the architechture at this moment.
So basically we want to keep a service oriented architecture using MVC web api.
So I had the following structure in mind:
Project.Core (All Poco classes)
Proect.Data (All entity framerwork)
Project.Service (All Web API ??)
Project.Web
We would be working for the first time on webapi here. So wanted to know how do we intergrate webapi here.
Most of the articles we saw read had created a mvc web application and had selected webapi in that. But we
were looking to create separate service layer just for webapi. Is this the correct practice to do that or
I am missing something here.
We basically wanted not to have a tight coupling b.w MVC web and web api here. If we create web api as part
of mvc then how can we separately access our web api.
WOuld appreciate inputs.
I normally use the project template provided by Visual Studio. Choose Empty ASP.NET project template and then select Add folders and references for Web API. It will create the folder structure needed/recommended purely for a Web API project without any MVC reference. I generally create a separate project for Data Access and use that from the Web API project.
I've been checking quite a few examples related to Web Api, and they all create the model in the Models folder contained with the Web Api project but I'm curious as to how this should be handled if you want to use/re-use these models with various projects.
In the past, when using WCF REST, I would have created the following:
Business Model Project (PCL)
Business Layer Project
Data Layer Project
SQL Data Layer Project
WCF REST Project
Web App
Windows App
Third-Party Web app (javascript)
Mobile App (Xamarin)
Projects 2 to 9 would have all been referenced to Project 1 or objects would be created dynamically when using JavaScript. The business object project only contained POCO objects, most decorated with DataContract/DataMember attributes.
Can the same logic/Project breakdown be applied when using Web Api? Is it recommended or will I face problem at a later stage?
If it's not recommended, am I suppose to duplicate all my models? Doesn't seem to make sense so I thought I'd ask.
Thanks.
Short answer, YES. The same logic/Project breakdown can be applied when using Web Api. This is also how I implement my architecture. Your Web Api would just be another layer in your architecture. By doing it that way you will allow for greater re-usability of the models (DRY) and maintainability.
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
Maybe this is a stupid question, but I dont know how to use Membership in sharp architecture template. I have seen how it is done in asp.net MVC (with AccountController, AccountView, and AccountModel / all of them autogenerated and binded to membeship provider).
I hope that my question is clear..
Thank you in advance.
You would need to implement your own membership provider and register in web.config, and then then have the required repository injected into your provider, or simply use the service locator to get the IRepository.
Mauricio Scheffer has written a post about injected membership provider using windsor which should help you get started.
I am creating my first ASP.NET MVC 3 application, and my data comes from a data source I can access only via its REST API.
I will only be using READ-ONLY access at this point to the REST data source (no updating, etc.)
I would like to use the Entity Framework V4 to provide a Business Entity interface to MVC 3 without exposing it to the REST API.
I need to get something working quickly - so I don't have time to fully understand the Server Layer / UnitOfWork and Repository patterns just yet, although I plan to go there next.
I am willing to use a Repository class at this time, but not ready for DI / IoC container yet.
Any suggestions on where the RESP API calls go?
EDIT
Learned by asking this question that it is not necessarily useful to integrate an ORM with a REST API - See my accepted answer below.
An Object/Relational Mapper, or ORM, like Entity Framework has specifically been developed to abstract away a relational database. It might not be the right fit for REST calls.
You could instead build a repository class that encapsulates the REST call and exposes methods like IEnumerable<T> GetAll() or T GetyById(...).