I am developing ASP.NET (WebForms) app and using EntityFramework. I was wondering what is the best practice of using entities. Create few entities for whole database or create many entities for specialized purposes ?!
Example case is this:
I have customers table. This table have ForeignKey to customers_addresses and customers_phones tables. I got two cases on this dataset
Autocomplete customer name
Show user details
For case 1 I got one entity which have only the "name" column mapped to user to db
For case 2 I got another entity which have all data and connections between other tables.
Now I was wondering if only single entity (number 2) would be good for both cases.
What's the best practice with EF ?
I don't see a reason, in your case, to have a specialized entity for the autocomplete scenario. Since you'll be using Linq to Entities for all your querying, just make sure you are selecting just the Customer Name from the entity, instead of the entire entity itself
from Customer cust in ent.Customers
select new {
CustomerName = cust.CustomerName
};
That way you still have lightweight SQL query on the backend, but you're not polluting your models with unnecessary, "specialized" entities.
In addition, if you're using lazy loading then you don't have to worry about EF loading any related entity information unless you actually need it.
Related
I'm working on a database schema that involves two static sales agency that have the same database model.
For example:
dbo.User becomes
paris.User and toulouse.User
Our project works with Linq To SQL and we use sqlmetal to generate two map files one for the Paris agency and the other for Toulouse.
With active directory, we are able to detect where the user come from and by that, we choose the map file corresponding to his agency.
My question is:
Is there a way to do the same in Entity framework ?
if not, what can i do ? and what's the best solution that i should follow, while using Entity framework.
You can have multiple dbcontext in entity framework so depending on your agency you can use the different dbcontext.
Is it good practice to delete properties (columns) that are not required from entity framework 6 model that is auto generated using database first approach? If not then what is the alternative.
Please explain.
It is not a a good idea. The model generated is a representation of your database. Rather re-design your database tables to include only the columns you want. If you delete the properties from the code-generated model the schema will be wrong and you will run into problems.
If you do not want to delete the database columns, then you can use code first and map your model to the existing database columns.
I have an odd situation. I am working on a project with a very large existing database that is completely unrelated, but does contain corresponding table id's. It's as if someone copied the database but never related the tables.
In Entity Framework, is there a way to go EF code first and create the relationships in code, but Not apply those relationships in the database? I would like to go through and relate the database but the client doesn't want to pay to fix it.
Thanks!
In this instance, it seems you would be best to add relationships directly to your database (or to a duplicated database for testing/staging) and then just update your entities using your test connection and regression test your app.
I am working in an asp.net MVC 4 application and I am using Entity framework 6 in my application. I am using both code first approach for new tables/entities as well as database first approach with model designer(edmx). Customers are in codefirst model with separate context where as vehicles are in edmx. both have different context object. I want to use a query like this:
return View(maindb.Reservations.Include("customer").Include("Vehicle"));
but it returns error:
A specified Include path is not valid. The EntityType 'myproject.Data.Reservation' does not declare a navigation property with the name 'Vehicle'.
Please suggest how to fix it so that I can get properties of Vehicle and use them in my view.
I am using both code first approach for new tables/entities as well
as database first approach with model designer(edmx)
Wrong way to go.
Please suggest how to fix it
Put those entities into the same context.
You need to choose which approach is more suitable for you. For example, code first works as well with existing tables. If your tables don't match the naming conventions, you can easily override them with data annotations or fluent API, which is very flexible (see http://msdn.microsoft.com/en-us/data/jj591617 and http://msdn.microsoft.com/en-us/data/jj591620).
I have a database that relies on a bunch of Many-to-Many and rather than denormalizing the whole database (which is quite large) I would like to know if there is a SIMPLE way of implementing Many-to-Many Relationships using LINQ-to-SQL Yet...
Everywhere I look I find articles on HOW Difficult It is, or A Simple Workaround that is actually "NOT" Simple. But all the articles I have been able to locate are pretty dated, using asp.net 3.5.
Should I just Create a Stored Procedure and then Drag it into the .DBML file as a method?
So I guess my question is:
Is there any new way to implement many-to-many using Linq-to-Sql in ASP.NET 4.0 along with MVC 3.
Examples of usage in my Project:
In the finished model, there will be Other Tables linked to the Many-to-Many Tables (i.e. EventAddress, EventUrl, VipAddress, VipPicture, GuestAddress, GuestPhone, GuestEmail, etc...)
So you can see when this would be a pain in the a$$ to denormalize.
Thank you,
Tim
Have you considered using Entity Framework?
It handles m:n relationships nicely. In your case the EmployeeAddress table would be abstracted away as a list of addresses on your Employee object.
It is also my impression that linq to sql isn't really a priority for Microsoft, EF Is.
I understand if you do not wish to convert an existing project, but for new projects EF4 would probably be a better fit.
LINQ to SQL will always map directly to the structure of the database. If your database has all of those junction tables, then they will be in your LINQ to SQL model - period.
Although you can map many-to-many relationships in both LINQ to SQL
and LINQ to Entities, LINQ to Entities allows a direct mapping of
many-to-many relationships with no intermediary class, while LINQ to
SQL requires that an intermediary class map one-to-many to each of the
classes that are party to the many-to-many relationship.
link to the quote above - http://msdn.microsoft.com/en-us/library/cc161164.aspx