I have a repository pattern in my application, to implement the repository i use Linq to SQL, but apart from the automatically generated entities, i create my own entity classes to maintain abstraction.
The problem is when i try to update entities.
Since i fetch from the repositories the custom entities that i created, and not the ones that Linq to SQL created, all changes that i do to the fetch entities are not recorded by the Linq to SQL mechanism.
So when i write:
dbContext.SubmitChanges()
Nothing happens.
What can i do to solve this?
Thanks,
Arik
I have done a couple of projects with the same pattern that you are using. What I did was, before calling the dbContext.SaveChanges(), load in the corresponding generated entity or entities from the database and then copy over all the fields from the custom entities that were edited to those loaded entities.
Related
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 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
I want to use Entity Framework to a load a number of sql tables into memory from my c# app before performing some work on them and sending changes back to the database. I only want to hit the database once when I load the data and once more when I update changes. Should I load the tables into a dataset or is there a better way to achieve this?
In such case you can't use entity framework. Entity framework will hit database for once for loading each table (unless there are relations which can load all tables in single query as #Jakub suggested) and it will hit database for each performed change. EF doesn't have command batching and each modified, inserted or deleted entity will cause separate roundtrip to DB.
Turn off lazy loading or use Include() to specify related entities that should be loading in a single query.
If you're using CTP5 look here: http://blogs.msdn.com/b/adonet/archive/2011/01/31/using-dbcontext-in-ef-feature-ctp5-part-6-loading-related-entities.aspx
I have an edmx file that reflects 100% my DB schema.
Along with this I need to create some custom Entities based on the existent, pretty much like a view that will aggregate fields of several entites into a single one.
The problem is that this isn't quite working. I tried several approaches but it always gave me conflicts with the actual entites already on the edmx.
I need to have those entities that reflect my DB schema, so do I have to create another edmx file to hold my custom entites and avoid colisions?
I also though of:
create a stored procedure but then if
I need to filter the SP result I
eather have to add support for serach
on the SP of get all the rows and
filter with Linq2Objects... won't do
this!
create a View, and this one would
work pretty well but I want to try
to do this making use of the EF4
designer and keep everything in one
place.
Could anyone point me to some examples?
I think what you are describing is a view so this is probably the right way to go.
You can store the view code in the edmx using the DefiningQuery node. You don't need to create the view in the database. However there is no designer support for this feature, you will need to hand edit the edmx. The changes you make should be persisted if you refresh the edmx from the database using the designer.
Details here:
http://msdn.microsoft.com/en-us/library/cc982038.aspx
http://blogs.msdn.com/b/davidebb/archive/2010/10/01/the-easy-way-to-create-an-entity-framework-defining-query.aspx
It would be easier just to create the views in the database, and let the designer find and model them.
This entity will be read-only, but of course you can then assign SPs for UPDATE/INSERT/DELETE if you want to support modifications via this view.
You can't define two entities based on same table except special cases (table splitting, hiearchy mapping). In this case you have to use DefiningQuery as #James suggested or QueryView. The difference is that DefiningQuery is defined in storage model and it is common SQL. QueryView is defined in conceptual model and it is ESQL defined on top of already existing entities. QueryView supports only some features of ESQL (for example it doesn't support aggregate functions). In both cases you have to modify EDMX directly (XML), these features are not supported in designer.
Database view mentioned by #James is also an option if you don't want to use these advanced EF features. You can as well simply expose predefined queries on your object context and map return projection to custom type.
Be aware that neither of these methods will allow you to modify, insert or delete data.
My company uses stored procs for all SELECT operations so it's making it rather difficult for me to create sensible navigation properties. I'm not too concerned at this point whether they're lazy loaded or not.
So for example I created an entity for Customer then created a FunctionImport to map GetAllCustomersSP to return a collection of Customer entities. But I want a navigation property "Orders" on each Customer entity.
But if I use the Customer entity partial class to just add this property, the problem is that I don't have access to the original Context, so I can't call the GetCustomerOrdersSP either explicitly or deferred.
The only option I can see is to modify my repository to add these properties in explicitly, which seems lame because it puts the entity logic into the repository.
Is there something I'm missing here? I can see in the entity model designer that I can specify custom insert, update, delete SPs but I don't see any way to use select SPs to actually retrieve the data.
I agree with Tim here...any solution you come up with isn't going to fully leverage the ORM and will be a potential nightmare to maintain. I would suggest creating a model, in code, that is framed in the manner in which you want to develop.
In the Data Access layer of your app, you can map your data objects that use SPs to hydrate your model objects (have a look at AutoMapper). Your app will only know about your model objects.
Doing this will give you a consistency in how you interact with the objects, and you can begin to apply pressure to the powers that be to allow more fine grained access to the tables, at which point, you can adjust your Data Access Layer to support EF and remove SPs. At this point you would be able to consider migrating the objects you created to POCO objects that are persisted via EF.
We had a similar issue in that granting raw DB access was "forbidden". We overcame this problem by using a model in which we only grant access to tables as they are used, not the entire database, and by ensuring the DBA that EF uses parameterized SQL, eliminating the concern of SQL Injection.