Hi. I’m working on a solution which consists of layered mvc application using entity framework. I want to use AspNet Identity to manage user accounts and logins. Which has its own model and dbcontext classes embedded in it and all of these are inside my UI MVC project.
But I don’t want this. I want to be able to manage my database interactions through data layer which is entity framework and my own DB context. Now for a simple user account in order to be related with my custom Person class, I should do two separate database insert commands. One for create user and one for its related person object. I did merged two separate databases as one, but for contexts I still don’t know what to do.
Am I in the right direction or I’m missing something? Is there any best practices for this type of problems? I’m sure this has been solved for many people but I can’t figure it out how. I searched around for solutions on this problem but I couldn’t find anything useful. Thanks in advanced.
have you tried inheriting your context from IdentityDbContext?
Related
I've just finished creating a custom surface controller that sends out emails after a user has filled in details of a contact form.
However I'm trying to now store these records in a custom table but I'm not sure what available methods I have of doing this? In previous versions of Umbraco ie. < 4.8 I'd create Linq 2 Sql classes and then save my records using the DataContext object.
Now that Umbraco 6 has moved to MVC I'm a little unsure how I should proceed. I've been looking into using Entity Framework to add my custom records but now I've just seen this article and I wonder if there's another simpler way of adding these new records to my database?
Is anyone able to point me in the right direction here? What is the optimal way of adding records to custom tables in umbraco 6?
Thanks!
There are two answers to this question:
Use a framework/solution like EF;
Use Contour
If you haven't looked at it, Contour is an Umbraco plugin that does exactly what you need. See here for more information about Contour.
However, for more control I use PetaPoco or more recently NPoco (via NuGet) and also Autofac to inject the Database (analogous to DataContext) into the constructor of my Controllers.
This is super easy and if you aren't already using an IoC container like Autofac in your builds I would highly recommend looking into it. Especially if you stick with EF, as you could ensure that a single DataContext object was created and disposed for each request, making sure that you didn't have multiple contexts floating about.
So I want to build an application with MVC 4 and Entity Framework 5. I've build simple applications before, but now I need some security around my current effort... I have some confusion / questions that I was hoping someone could answer;
First... Using the MVC 4 Internet Application Template it implements SimpleMembershipProvider. I have read every primary article about modification, implementation... However, this uses a Code-First implementation...
Problem: I have an existing database that I would like to import the scheme for to an EDMX database first approach... How do I implement the MVC 4 Simple membership provider when my database ties tightly and directly into the user table (userid)?... I know I can use my own user table as long as i designate the userid and username fields as documented... Will this affect the provider, or the existing "AccountController" code? Will these need to be modified?
Second, what I am looking for is a workflow with this architecture... I am "old school" mostly database first approach... My project is a huge WIP (work in progress). I have a foundation, but will need to expand as needed... Can someone provide some insight into database first vs other approaches when there will be quite a bit of change management occurring?
you can still use Code First to map to an existing database. You may need to explicitly map properties to table columns because the mappings do not follow the default conventions, but that doesn't prevent you from using Code First.
When transitioning from DB first to another mindset. Focus on how the objects interact with each other. then, at some point you will save the state of the objects after they interacted. This is where the ORM comes into play. detects changes and executes the necessary SQL statements to persist the current state of the objects.
Think of the database as just another storage container. In theory it could be replaced by another persistent storage mechanism (document db, file, persistent hash table, in memory list, etc.). In reality it's not that simple, but the idea of treating the DB as just a simple storage container helps to break away from the monolithic database concept that is/was ingrained into most devs.
But don't loose perspective of the design either. If it's a simple forms-over-data app where you will be adding features in the future than keep the design simple. than don't try to totally abstract the DB away. you know it's there and the relationship to the UI is almost 1:1, so take advantage of that.
In it's simplest form separation of concerns can be achieved by using the MVC controller to manage the interaction between the model (mapped to the DB via ORM) and the view (razor templates) my personal preference is to keep ORM out of the views so I typically query the database, map the domain model to a viewmodel and then pass the viewmodel to the view.
Again if it's a simple application and screens map directly to the database than viewmodel are probably overkill.
My company has a product that ultimately exposes a bunch of object types that I want to be able to interact with via a custom DbContext and DbSet classes so that I can perform CRUD activities against them in an MVC based website.
So basically what I want to do is have the equivalent of DbContext (http://msdn.microsoft.com/en-us/library/gg679505(v=vs.103)) and DbSet such that they are not tied into a database in the background, but point at our server product instead.
But I have no real idea on how to do this. Is this even possible or would it be some kind of nightmare to achieve. I've searched around but have not had much luck finding anything of this nature, which probably indicates that it is a nightmare.
Any pointers in the right direction is much appreciated.
Thanks
See if this helps: Write a custom DbContext
I recently finished an application using just standard grails way (GORM-domain classes, etc.), but the company is asking me to to include an existing DB from an open source project. Both are just using mySQL DB, which is good, but I'm not sure how to approach this. I've seen some posts regarding grails connecting to multiple DB.
I guess my question is: Is it possible to connect to two databases: one mapped to domain classes and the other not? My primary reason to do this is to keep all the code in one project and reuse code without gutting the project and making a plugin.
Thanks for any insight.
Yes. It is possible - http://grails.org/doc/latest/guide/single.html#multipleDatasources
Whether you map the other database to your domain classes or use it through a service layer is up to your design.
Thanks for the answer. I was also able to find a tool that helps generate the domain class from an existing DB. The tool is called GRAG (Grails Application Generator) which although is not perfect, it is a bit of a help getting me started faster.
I hope this helps others as well.
I'm just starting a new project on ASP.NET MVC and this will be the first project actually using this technology. As I created my new project with Visual Studio 2010, it created to my sql server a bunch of tables with "aspnet_" prefix. Part of them deal with the built-in user accounts and permission support.
Now, I want to keep some specific information about my users. My question is "Is it a good practice changing the structure of this aspnet_ tables, to meet my needs about user account's information?".
And as i suppose the answer is "No." (Why exactly?), I intend to create my own "Users" table. What is a good approach to connect the records from aspnet_Users table and my own custom Users table.
I want the relationship to be 1:1 and the design in the database to be as transparent as possible in my c# code (I'm using linq to sql if it is important). Also, I don't want to replicate the usernames and passwords from the aspnet_ tables to my table and maintain the data.
I'm considering using a view to join them. Is this a good idea?
Thanks in advance!
EDIT: From the answer, I see that I may not be clear enough, what I want. The question is not IF to use the default asp.net provider, but how to adopt it, to my needs.
I would create custom membership provider and omit those aspnet_x tables completely. I've seen what happens when one joins these tables and custom ones with nhibernate mappings - pure nightmare.
If you are choosing to use the Membership API for your site, then this link has information regarding how to add extra information to a user.
I was faced with the same scenario recently and ended up ditching the membership functionality and rolled my own db solution in tandem with the DotNetOpenAuth library.
Using the membership system in asp.net has its advantages and drawbacks. It's easy to start, because you don't have to worry about validation, user registration, resetting passwords. (Be careful if you plan to modify the table structures, you will have to change them in the views/store procedures generated
However there are drawbacks to using Membership
You will have to maintain 2 separated systems, because the Membership API has restrictions, for example, you cannot perform operations inside a transaction with the membership api. (Unless you use TransactionScope i think, but you don't have other choices).
A valid alternative would be to implement your own security validation routines, and using FormsAuthentication. This way you will have total control over your users tables, and remove dependency to the membership API.