i'm new in Entity Framwork, and I have a problem with SaveChanges() method:
I have only a overload with no parameters; I don't have SaveChanges(Option) or SaveChanges(Bool). Why?
I am pretty sure the SaveChanges(bool) was an old ObjectContext method.
I imagine it is now deprecated in favour of SaveChanges()
SaveChanges() works on state modifications that are stored automatically when you do CRUD operations. That's the reason why nothing more is needed.
Be sure to call SaveChanges() at the good moment in your code, to ensure that relational constraints are good (for foreign key consistency).
Related
I am trying Abp framework recently and happily found that it is a wonderful implementation of DDD. But since it uses AutoMapper to translate DTOs into Entities/Aggregates, I have noticed it's able to short-circuit my private setters of Aggregates, which obviously violated the main rule of DDD. Although the goal of AutoMapper is to reduce manual operations, but DDD emphasizes invariant through private setters.
How can I make there two seemingly conflicting concept clear and use this framework smoothly? Does that mean I have to give up AutoMapper to keep DDD principles or vice versa?
I believe AutoMapper is not an anti-pattern of DDD since it's very popular in the community. In another word, if AutoMapper can use reflection (as I know) to set private setters, anybody else can. Does that means private setters is essentially unsafe?
Thanks for anyone could help me or have me a hint.
AutoMapper is: A convention-based object-object mapper in .NET.
In itself, AutoMapper does not violate the principle of DDD. It is how you use it that possibly does.
How can I make there two seemingly conflicting concept clear and use this framework smoothly? Does that mean I have to give up AutoMapper to keep DDD principles or vice versa?
No, you don't have to give up AutoMapper.
You can specify .IgnoreAllPropertiesWithAnInaccessibleSetter for each map.
Related: How to configure AutoMapper to globally Ignore all Properties With Inaccessible Setter(private or protected)?
In another word, if AutoMapper can use reflection (as I know) to set private setters, anybody else can. Does that means private setters is essentially unsafe?
No, that means that reflection is very powerful.
Don't know a lot about the Abp framework. Private setters is just good old traditional OOP which is used in DDD (encapsulation). You should expose public methods from your aggregate that will change its state. Automapper can be used in your application layer where you map the DTOs to domain building blocks (like value objects) and you pass them as parameters in your aggregate public functions that will change its own state and enforce invariants. Having said that not everyone loves Automapper :)
How can I make there two seemingly conflicting concept clear and use this framework smoothly?
By configuring AutoMapper's profile to construct the aggregate root using a custom expression that uses the aggregate's factory methods or constructors. Here is an example from one of my projects:
public class BphNomenclatureManagerApplicationAutoMapperProfile : Profile
{
public BphNomenclatureManagerApplicationAutoMapperProfile()
{
CreateMap<BphCompany, BphCompanyDto>(MemberList.Destination);
CreateMap<CreateUpdateBphCompanyDto, BphCompany>(MemberList.Destination)
// invariants preserved by use of AR constructor:
.ConstructUsing(dto => new BphCompany(
dto.Id,
dto.BphId,
dto.Name,
dto.VatIdNumber,
dto.TradeRegisterNumber,
dto.IsProducer
));
}
}
My question here is if I should place a RowVersion [TimeStamp] property in every
entity in my domain model.
For Example: I have an Order class and an OrderDetails "navigation, reference" property,
should I use a RowVersion property for both entities, or is it enough to the parent object?
These classes are pocos meant to be used with Entity Framework Code First approach.
Thank you.
The answer, as often, is "it depends".
Since it will almost always be possible to have an Order without any OrderDetails, you're right that the parent object should have a RowVersion property.
Is it possible to modify an OrderDetail without also modifying the Order? Should it be?
If it isn't possible and shouldn't be, a RowVersion property at the detail level doesn't add anything. You already catch all possible modifications by checking the Order's RowVersion. In that case, only add the property at the top level, and stop reading here.
Otherwise, if two independent contexts load the same order and details, both modify a different OrderDetail, and both try to save, do you want to treat this as a conflict? In some cases, this makes sense. In other cases, it doesn't. To treat it as a conflict, the simplest solution is to actually mark the Order as modified too if it is unchanged (using ObjectStateEntry.SetModified, not ObjectStateEntry.ChangeState). EF will check and cause an update to the Order's RowVersion property, and complain if anyone else made any modifications.
If you do want to allow two independent contexts to modify two different OrderDetails of the same Order, yes, you need a RowVersion attribute at the detail level.
That said: if you load an Order and its OrderDetails into the same context, modify an OrderDetail, and save your changes, Entity Framework may also check and update the Order's RowVersion, even if you don't actually change the Order, causing bogus concurrency exceptions. This has been labelled a bug, and a hotfix is available, or you can install .NET Framework 4.5 (currently available in release candidate form), which fixes it even if your application uses .NET 4.0.
When doing managed objectmapping with RestKit, using core data, i map using my NSManaged subclasses fe. User.m
And that works fine.
But if i need to do ordinary objectmapping it is not possible to still use the NSManaged Subclass - User.m, as the mapping object.
I then have to create a new object, subclassing NSObject, with the exact same ivars i.e. UserOBJmapping.m
This is kind of a waste, and i wonder if there is a more clever way to do it, so i do not have to create classes that have the same internal structure.
The reason why i have to do this, is that whenever RestKit maps an incoming objectstream to User, it is put directly in the store, and i have situations where i need the data not to be store, but simply be in my cache memory for manipulation.
Just like i do with normal Object Mapping.
I think there properly is a way to do this with managed objects in RestKit but have found no info about it anywhere.
I hope that someone might have a some idea for achieving a more clever solution.!
Thanx
It's a limitation in Core Data. You can't have NSManagedObject instances without a context.
Can RestKit map to a dictionary instead?
I am using NHibernate for persistence, but i read somewhere that NHibernate acts as unitofwork container. So do i need to create a separate UnitOfWork implementation. ?
Or continue with Nhibernate's unitofwork.
You don't need to create separate UoW implementation.
I suggest you to read this post: nhibernate.info
According to Martin Fowler, the Unit of Work pattern "maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems."
Nhibernate internally already implements this pattern tracking all the objects has been modified (added,updated,deleted). You don't need to do anything because it already use this pattern itself
just to make this concept clear it is like if for each row of your resultset there is a "magic" column that says if the row has been added,updated or deleted
I have an object that gets instantiated in a linq to sql method. When the object fields are being assigned, i want to check a date field and if it is an old date, retrieve data from another table and perform calculations before continuing with assigning this object.
Is there anything wrong with triggering such an event through the property setter Or should I independently check the date through some service and make the changes if necessary at some point aftwewards?
There's nothing wrong with doing some logic from within your setters, but you should be careful about just how much logic you put within your setters. One of the fundamental problems of setters is that since they act like attributes, but have backing code, it's easy to forget that there are potentially some non-trivial actions going on behind the scenes.
This sort of thing can cause problems if you have accessors which use accessors which use accessors; you can rapidly end up causing unexpected performance problems. Generally, it's a good idea to keep the actions of setters (or getters, for that matter) to a relatively small set of actions. For example, validation can work perfectly fine in a setter, but I'd generally advise against doing validation against external resources, because of two things: first, resource delays can cause problems with expected access speed, and secondly, the number of external resource accesses can destroy your performance.
Generally, the rule is this: keep it simple. It's not unreasonable to do complicated things in a setter, but if you do, it's really important to understand the consequences of all of the actions you'll be causing, and it's EXTREMELY important to document what it does extremely well, so the next guy (or girl) to use the code doesn't just try to naively use the accessor and end up causing massive resource contention issues unexpectedly.
Half the point of using setters instead of, say, public fields, is to be able to trigger events associated with setting certain data.
Keyword: associated. If you're just using the setter as a "convenient" time to do some other stuff because it happens to work, you're doing it wrong. If setting this value requires other work to be done, then by all means, use the setter to do it.