Which one to choose either ObjectContext or DbContext, when the requirements are,
Data Modeling done by Modeler and provides the DEV team a sql
script. Due to this we have opted Model First. Is this a correct
choice ?
Existing denormalized db will be migrated to new db created by
modeler
Need to maintain audit log for all the updates, at the field level,
from the UI
Each table has CreatedBy, CreatedOn, ModifiedBy, ModifiedOn. These
fields should be automatically filled by during
context.SaveChanges().
If you're starting a new app, just use DbContext. You can always drill down to ObjectContext if you need to.
If you prefer no designer, you can use Code First with Migrations and create a SQL Script via update-database -script as well.
Sounds like a task for the DBAs?
field by field changes..If this is a disconnected app, you'll be better off handling that outside of EF (IMHO)
you can easily override SaveChanges for this. You said in a tweet that you have the dbcontext book. There's an example of this where we do this using a base class. However if you are going to use model first, be sure to avoid this problem : http://msdn.microsoft.com/en-us/magazine/jj553510.aspx
Thanks a lot Julie for your super quick response. You are The-EF-Angel.
I have read your MSDN article on Logging in EF.
To your reponse:
1. As a mandate, We need to use sql scripts provided by our Modeler to create our db. Also these scripts will be keep changing(With addition of new tables & update of exising schema) for each sprints. Hope DataFirst Model is fine. Whenever new we get new sql scripts, we plan to recreate the DB and update our EDMX. Do you see any issues with this approach ?
2. Ya we have a migration specialist for this task. I justed pointed that in question as an FYI.
3. We use MVC app and for field by field changes in audit log table, we planned to let EF decide what fields have changed(using change tracking ideas from your book) and capture that info into a DTO(we borrow your repository ideas from the course "EF in enterprise course" you authored in PS). And push that DTO into our messaging infrastructure and that will insert the audit logs to the DB.
Is this fine ? Do you foresee any issues ?
4. As you pointed out, we could change our interface for our needs by referring to your MSDN article and there "Figure 3 Setting the Interface’s DateCreated Property During SaveChanges"
I plan to use,
public interface ITheBaseType
{
DateTime DateCreated { get; set; }
DateTime DateModified { get; set; }
string CreatedBy { get; set; }
string ModifiedBy { get; set; }
}
Related
I have two table in my database. Table USER and table USER_ADDRESSES
Table USER has UserID , UserName , HumanName
Table USER_ADDRESSES has UserAddresseID, UserID, Address
The two tables are related through the UserID foreign key.
I am working code first. The POCOs are as one would expect I guess:
Public class User
{
Public guid UserID {get;set;}
Public string UserName {get;set;}
Public string HumanName {get;set;}
}
Public class UserAddress
{
Public guid UserAddressID {get;set;}
Public guid UserID {get;set;}
Public string Address {get;set;}
Public virtual User User {get;set;}
}
If I POST a user, it flows through EF and into the physical database - cool
If I POST a UserAddress with the UserID foreign key properly assigned as the UserID of the above user, the userAddress flows through EF into the physical database - perfect.
Now as I am learning this subject, I like to test scenarios that I know will cause errors… Understanding how something fails often leads to greater understanding (IMHO).
To this end, I repeat the above steps. POST a user, then POST an Address but this time with an empty GUID in the Address.UserID property, something I know will cause SQL server to error on, this time EF gets an error back from the DB and surfaces that error in my controller class as a DbUpdateException, which I then act upon to send back a BadRequest ErrorResponse, this would be fine except now I can post nothing to the DB, If I subsequently try to post new Users EF throws a DbUpdateException on every POST. The only way out of this condition is to Stop debugging the WebAPI project, kill IISExpress and restart everything.
My suspicion is that it is something to do with the tracked entities in dbset.Local it appears this collection is happy to store entities which violate database constraints, and even after the DB has thrown an error EF does not remove the faulted entity from its cache, and I guess that every time I call DataContext.SaveChanges(), EF keeps trying to submit the Faulty address entity that it has in it's bdset.Local property and thus prevents me from submitting anything further to the DB until the whole project is restarted and the various dbset.Local collections are flushed.
Ok I understand that, In my controller class I can prevent some of these issues by evaluating the various properties of the object before submitting them to my repository/UnitOfWork and thus prevent them from getting into dbset.Local in the first place, perhaps there is some decoration I can add to my POCOs such that ModelState.IsValid returns false if UserID == Guid.Empty in the UserAddress Entity??? . But surely EF should be able to recover from DB originated errors, such that if an INSERT statement fails when run against SQL server, EF should remove the faulting Entity from its Local cache of tracked objects. Thus preventing the whole system from requiring a complete restart. The upshot of this is that if I had unique constraints on other non key fields, before I attempt to submit an entity I will have to query the DB to ensure that there are no records in the DB which would result in a DBUdateException from being thrown, that approach seems inefficient to me. I would rather take the error and throw it back to the client for them to consider.
Now perhaps it's my responsibility that on the occurrence of a DbUpdateException to do something to remove the faulted entity from the dbset.Local collection or similar. If that's the case how should I go about this?
As I have been writing this I am left wondering: Should EF not be able to recover from DBUdateExceptions in and of its self!? Without the need for an IIS restart. Or should I build my DB with no constraints what so ever and allow clients to put any old rubbish in there. It's my believe that EF Entity tracking should honour db constraints and prevent faulted entities from getting into the dbset in the first place.
Please guide me on the correct way to recover from a DBUpdateException?
Hi I have a question that is braking my mind for some days.
I have my SQL server Database and my C# application.
In the DB I have differemt tables, let me show you a simple ex
Tables:
Person
Relationship
City
Business Rules:
The person are from a City, so the person has IdCity
A person has a relationship with other person, and about that relationship you need to save the starting date.
In other projects I already did something like that, but in this proyect this is not working for me.
When I retrieved with LinQ the information about the person, the city is not coming, and an error appears when I try "person.city.description", for ex.
I try using Include("City") in the linq query, but it didn't work. Besides that, I don't know how to manage the circular reference to the person to person relationship.
One important thing, that I think that can be the problem, is that I rename all the tables from the DataModel, for example, the table in database is called Prd_City, so I change the Name and the Entity Set Name for City in c# project. So in the included I have to use the real table name, in other case the query fail, but if I use the real name nothing happens.
using (var context = new MyContext())
{
List<Person> oPeople = (from p in context.Person.Include("Prd_City")
select p).ToList();
return oPeople ;
}
Any help will be welcome.
Thanks!
"It didn't work" is never a good description of your problem. But from the rest of your question I can infer that Person has a navigation property named "Prd_City", while you expected it to be "City". The thing is: you renamed the entities, but not the navigation properties in the entities.
My advice (for what it's worth): it seems that your work database-first. If you can, change to code-first and manually map the POCO classes to their table names, and properties to their database columns. It may be a considerable amount of work (depending on the size of your data model), but after that you will never run the risk of EF "un-renaming" your entities. Besides, the DbContext API is easier to use than ObjectContext. Currently, it's the preferred EF API.
I'm using Entity Framework Code First and whilst I have working code, I'm having to make what are strictly unnecessary database calls in order to process the following update.
I have a simple POCO class for an album with a collection of related tags:
public class Album
{
public int Id { get; set; }
public string Title { get; set; }
public decimal Price { get; set; }
public virtual IList<Tag> Tags { get; private set; }
}
public class Tag
{
public int Id { get; set; }
public string Name { get; set; }
}
This is updated via an MVC form - with the tags represented by a series of check-boxes.
So when I get to my Update method in the respository, I have an album class populated with a list of tags - with in theory all I need to make the update.
However the only way I could find to get the list of tags to update (to delete any that were previously set but are now unchecked, and to add any that are currently checked) was to retrieve the original Album from the context and update it.
And secondly because in my implementation the Name field of the Tag is marked with [Required], and that in my Album object populated from the form I only have the IDs of the tags, I also have to retrieve each tag before updating.
Here's my code:
public void Update(Album album)
{
var albumToUpdate = GetById(album.Id); // - need to retrieve album with tags in order to update tags
albumToUpdate.Title = album.Title;
albumToUpdate.Price = album.Price;
albumToUpdate.Tags.Clear();
if (album.Tags != null)
{
foreach (var tag in album.Tags)
{
var tagToAdd = context.Tags.Find(tag.Id); // - need to retrieve full details of tag so doesn't fail validation
albumToUpdate.AddTag(tagToAdd);
}
}
}
Appreciate any thoughts as to how I could accomodate this with fewer database hits. It's not a major deal for this particular function (part of a site admin tool) but would like to know I'm doing things the best way.
Your approach - reloading the entity graph from the database and merge the changes manually into it - is correct in my opinion and the best you can do.
Forget for a moment that you use Entity Framework. What would you do if you had to write SQL statements manually? (EF is a wrapper around a SQL statement generator.) You get posted back an object graph - an Album with a list of Tags. How would you decide now which tags you have to write an INSERT, which tags a DELETE and which tags an UPDATE statement for? (I assume that your relationship between Album and Tag is many-to-many, so you write into a join table.) If you don't know the original state in the database you can't decide. Does the tag relation exist in the database or not? You have to query the database to find the answer, no matter if you use EF or direct SQL.
I see only two alternatives:
Track the entity changes yourself. For you MVC web application it would mean that you have to store the original state with the former GET request somewhere, for example in a session state or in hidden input fields in the page. With the POST request you can retrieve then the original state, build and attach the orginal graph and merge changes into it.
Write a Stored Procedure which takes the album and tag collection and let the SP do the work to create the appropriate SQL statements.
The first way is complicated and has its costs in HTTP payload (hidden input fields) or is depending on a fragile session state. And the second conflicts with why you are using an ORM. Unless you have really serious performance problems or are a SQL master I would not consider a Stored Procedure.
Firstly, I think that this pattern of updates is wrong somehow in that instead of passing in an Album which I assume is a replica or partial replica of the one you want to update (same ID at least), why don't you load the actual one first and apply your changes to it?
If you cannot do that, it might be less confusing to not pass in the same entity (Album) but instead use a data transfer object (DTO) or other message with just the fields you need and then apply that to the loaded Album.
As to the main problem of how to avoid loading each tag, EF should do that for you, but I don't know that it does. For example, NHibernate will not load a lazy entity if you are only setting a relationship because you have not touched any properties of Tag, so it only needs the Id to use it. Hopefully, EF does the same but maybe not (I'm assuming you've profiled it).
If EF does not behave like that you could try two things: firstly, so long as there is no cascade update on Tag, use a skeleton one with just the ID (that is, create the object yourself and just set the Id); this won't work if EF cascade updates the Tag. Secondly, you could implement your own cache for Tags and get them from memory.
I am designing a project in asp.net mvc3, i have designed my database in sql server, add i am using ado.net.
This is my controller action
public ViewResult ProductFormulationIndex()
{
return View(db.ProductFormulation.ToList());
}
means i want to display all fields of ProductFormulation table.
this is my table:-
and this is my productCategory Table
in my ProductFormulationIndex.cshtml i want to display Code of ProductCategory Table, not only id. So what should i do in controller or in Model for it ?
you may suggest tutorial related to it.
Thanks in advance.
You need a view model which is specifically designed for the view.
When defining your view models you shouldn't be thinking in terms of tables. SQL tables have absolutely no meaning in a view. Think in terms of what information you need to show and define your view models accordingly.
Therefore, You can define a view model like:
public class ProductInformation
{
...
public string CategoryCode {get; set;}
...
}
Or public Category ProductCategory.
You can use AutoMapper to convert between your real models and the view model you have defined.
You can find a good tutorial at http://weblogs.asp.net/shijuvarghese/archive/2010/02/01/view-model-pattern-and-automapper-in-asp-net-mvc-applications.aspx
Although I may not answer your question you are touching on some interesting points.
I subscribe to the school of thought that says one should not query an object model but rather make use of a denormalized lightweght query layer.
You will pobably quickly run into the lazy-loading and projection issue: i.e. you do not always require the related data and you do not always require all the fields. A query layer takes care of this quite nicely since using a denormalized model means that when you do your query you do not need to do N-number of joins to get the related data. You will still at some point need to gather up the data but you actual view queries will be order fo magnitude faster.
Also, getting all the data (by joining) for your denormalized model is a once-off affair as opposed to doing it each and every time you display the relevant data on the front-end.
Hope that makes sense :)
Is it a good idea to create a lighter version of an Entity in some cases just for performance reason pointing to same table but with fewer columns mapped. E.g If I have a Contact Table which has 50 Columns and in few of the related entities I might be interested in FirstName and LastName property is it a good idea to create a lightweight version of Contact table. E.g.
public class ContactLite
{
public int Id {get; set;}
public string FirstName {get; set;}
public string LastName {get; set;}
}
Also is it possible to map multiple classes to same table?
Don't map multiple classes to the same table. I tried this once and though it worked for what I was doing, I'm sure it would have bitten me later. It's better to use projections to populate the "light" classes.
It's not a good idea. Instead, always map the full class and create smaller ones that you can project on using Transformers.AliasToBean or LINQ.
An example of the latter:
var lightContacts = (from contact in session.Linq<Contact>()
where contact.Country = "Argentina"
select new LightContact
{
Id = contact.Id
FirstName = contact.FirstName,
LastName = contact.LastName
})
.ToList();
This will only select those three fields from the DB, even when filtering by a different one.
It's worth noting that, with LINQ, you could also use an anonymous type to select any projection you want without creating additional types or mappings.
I used this approach for handling an Entity without a BLOB-field (just for handling relations etc).
I had some issues regarding Implicit polymorphism, meaning I had this setup:
public class ImageWithData : Image
The inheritance made NHibernate load an ImageWithData in a second roundtrip every time I resolved an Image directly (not when related with BelongsTo or HasMany).
There is an option in NHibernate to disable this behaviour, called polymorphism="explicit" which you specify on your base-class (in my case, Image).
If it will be bad design in your case, I don't know, it all depends on why you need to lighten your entities.