How is everyone designing their EF models when using the built in ASP .NET Membership functionality?
I have many entities (blog posts, comments, photos, etc.) which have a user id associated with them. I currently have a User model that maps to the aspnet_User table, but there is lots of sketchy code juggling around both the MembershipUser entity and the User model which I've created.
Does anybody have any clever solutions I may be overlooking to merge the two entities while still using the included membership functionality?
What I have done in this situation is to create a View in SQL Server, which selects from my own User table and joins one or two columns from the ASP.NET tables. I then map my User entity to this View using ToTable() in DbContext.
This works well enough for me; just note that you cannot use an UPDATE statement on a SQL View if it affects columns from more than one table, so the properties from the ASP.NET tables should not be modified via EF (how you enforce this depends on your implementation).
Related
I’m looking forward to creating a multitenant-based SASS application. I have defined database design like each tenant using different databases (Postgres) with standard objects(tables) like contact, and accounts. So far clean, I can see many SaaS application supports Custom Object(tables), where customer can create their own objects in real-time and required columns. I would want to support the same. Could someone please explain the backend logic behind that? How can we add new tables for custom objects in the database and refresh the DbContext entity at runtime?
Note: I’m aware for custom fields, many choice JSON-type columns in Postgres, it opens ways to add as many custom columns as JSON type in existing tables. But don’t find any recommended way to do custom object support.
EF doesn't really support adding tables at runtime. You can use ADO.NET queries to work with tables whose schemas aren't known at design-time.
I got an existing database with many tables which are accessed using stored procedures only (no O/RM). I'd like to create new tables in this database using Entity Framework and the Code First approach.
Do all the tables in my existing database need to be modelized in my Entity Framework classes? Will I be able to hand-code only the new classes I need in my DbContext? Other tables really need to stay untouched and away from O/RM for the moment.
Note: I'm going to be using the latest EF5.
As for now the Power Tools only allow you to reverse engineer all tables and views in the DB, which can be a problem if you have a big DB, with hundreds of objects, you do not want to reverse engineer.
However, I found an easy workaround for that:
Create a new technical user for the reverse engineering. To this user you only grant permission to the tables and views, that you want to be reverse engineered.
Have fun!
You are under no obligation to map any given table with EF. If you already have a database, you may want to consider reverse-engineering your database with the EF Power Tools available from Microsoft. I did this recently with a MySQL database that I had for testing purposes and it worked quite well!
If you are new to EF an advantage is that the PowerTools write a ton of code for you, which will help you get a grasp on the syntax of Code First. You will need to modify the output but it is a great start. I really believe that this approach will give you the least headache.
The EF PowerTools can be found here: http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d/
So, I've been searching for the answer to this, but I can't find anything
I have an Entity Framework Model (MyModel1) - for now, we'll say this contains a "Users" table
It's part of a big app, that has a references to an "Addresses" project
The addresses project contains an Entity Framework Model (MyModel2), this contains a Users table, and an Addresses table (pointing to the same database.
The main app has a control that edits the user, and in that control it has an "addresses" control which actually exists in the "Addresses" project.
To make this work, the User control passes the User object down to the addresses control, however, as the User that's been passed belongs to MyModel1 and not MyModel2, another User object has to be loaded up, then it can be used.
This isn't ideal as I've had to load up the User twice. Is there a way of say, MyModel2 extending MyModel1, which effectively just adds a relationship to "User". Or is there an ORM that would handle this better? Or even a design pattern that would handle this better?
I discovered Fluent NHibernate which seems to give me a load more control over how the data layer is put together, through some seriously crazy code I was able to extend the entities in a plugin kind of way, very cool
It sounds like today you have a projects that are a mixture of UI, business logic and data access logic.
A better approach would be to put your Data Access layer into a single project separate from the business logic and the UI. Create an EDMX that includes both Users and Addresses and provide a single ObjectContext that can be used to handle the whole process.
Take a look at the Repository pattern too.
I have to write a solution that uses different databases with different structure from the same code. So, when a user logs to the application I determine to which database he/she is connected to at runtime. The user can create tables and columns at any time and they have to see the change on the fly. The reason that I use one and the same code the information is manipulates the same way for the different databases. How can I accomplish this at runtime? Actually is the Entity Framework a good solution for my problem?
Thanks in advance.
You can do this with EF 4 using a code-first model. That said, I tend to avoid changing DB metadata on the fly, with or without EF. Rather, I'd choose a schema which fits the user's changing needs.
I'm in the process of looking around at options for a back office tool. On the face of it the tool is simple CRUD so I was immediately attracted to Dynamic Data on top of Entity Framework (we're definitely a Microsoft shop!).
The problem is that future requirement is to support versioning. By this I mean :
User performs a series of updates to a series of entities
When they are happy they submit the changes
Changes persisted to the DB along with enough info to support a rollback
Elsewhere we've got handcrafted app that :
Includes a version id that is incremented as each new row inserted - i.e. we don't update we add a new row
A work item table ties together the changes using the version id along with the entity type (table)
So, the question is, how would I achieve a similar end result using entity framework and dynamic data?
If entity framework, etc isn't appropriate - what would you use (.Net)?
Thanks,
Alan
One solution would be to move the logic for the versioning to database triggers. This way you are able to use a standard Dynamic data on top of Entity Framework, and retrofit versioning by running a set of database scripts.
I would like to mention that in the new Dyanmic Data Preview 3 there is a new feature DomainService which supports Roles based security please see David Ebbo's Serssion from MIX09 here Microsoft ASP.NET 4.0 Data Access: Patterns for Success with Web Forms MIX09-T47F