I try to pass from EF entity to dto in business layer.
So I setup Automapper and everything goes well.
Here is my profile class:
public DocumentProfile()
{
CreateMap<Data.Models.Docflow.Package, PackageDto>()
.ForMember(dest => dest.ReceiverName, opt => opt.MapFrom(src => src.Receiver.FullName))
.ForMember(dest => dest.SenderName, opt => opt.MapFrom(src => src.Sender.FullName))
;
}
But I make mapping from Package to PackageDto in different places of my code. And I have different specific queries in different cases. So I need to remember to include navigation properties Receiver and Sender in all queries.
So how can I incapsulate single query for Package entity with all necessary properties for certain projection?
I saw examples with value resolvers and type converters but it seems not suitable.
#lucian-bargaoanu, thanks for your comments!
Finally I came in to 2 suitable solutions.
Shared part is:
I prepare function like PackageDto Get(Guid packageId) in Repository and I incapulate dbquery with mapping to dto in repository and in BL I work only with dto.
But the difference is:
dbquery returns needed entity type in memory that is mapped then by Mapper.Map<>
dbquery returns IQueryable, that then extended by ProjectTo
Anyway It's necessary set profile with mapping rules, but second way is clearly as it performs includes that you need automatically.
Related
I'm trying to migrate my old app to the new EF Core but I cannot find some relationships like:
HasRequired(o => o.Document).WithOptional(o => o.CancelNote);
Is there some extension methods? I cannot find on the docs.
The HasRequired I think that is possible to substitute with HasOne() method, but how about the WithOptional()?
Other thing, according to the docs the entity not uses the virtual keyword to create the navigation properties, how lazy load will work?
You will not find an HasOptional equivalent method in EF7. By convention if your FK property is nullable, you navigation property will be treated as optional
modelBuilder.Entity<Blog>()
.HasOne(p => p.Document)
.WithOne(i => i.CancelNote)
.HasForeignKey<Document>(b => b.CancelNoteForeignKey);
About your second question,EF Core (EF7) doesn't support Lazy Loading. In this link you will find the options you have now to load related entities
I have .NET 4.0 WinForms Application, and I use Entity Framework 5 with Model First Approach. In VS EF Designer, I have created a dozen or so entities with a lot of scalar properties of String type, then in Properties Toolbar I have configured parameters (i.e. General parameters, Facets Parameters) for them, to fit DB requirements.
In BL layer I am able to validate entity object in purpose to check whether it contains correct values, for example by using DbContext.Entry(Of T)(entity).GetValidationResult() method. But I need to develop also GUI layer input fields validation for WinForms. I would like to implement dynamic GUI validation, based on metadata values of entity set properties, to have BL validation synchronized with GUI validation, and to avoid redundancy of source code written.
My question is: How can I get metadata values, particularly facets metadata values (i.e. Fixed Length, Max Length, Nullable) of auto-generated entities on runtime?
As I know, there is a possibility to take advantage of data annotations based on properties attributes in manually created partial class. However, in Model First approach, this solution may also involve redundancy issues and synchronization problems with metadata from VS EF Designer Properties Toolbar and Database.
This should help you get started, but you'd need to get to debugger and test specifically to get what you need...
A sample code...
using (var db = new MyContext())
{
var objectContext = ((IObjectContextAdapter)db).ObjectContext;
var baseset = objectContext
.MetadataWorkspace
.GetEntityContainer(objectContext.DefaultContainerName, DataSpace.CSpace)
.BaseEntitySets
.First(meta => meta.ElementType.Name == "YourEntityClassName");
var elementType = objectContext
.MetadataWorkspace
.GetEntityContainer(objectContext.DefaultContainerName, DataSpace.CSpace)
.BaseEntitySets
.First(meta => meta.ElementType.Name == "YourEntityClassName")
.ElementType;
EdmMember member = elementType.Members[2];
Facet item;
// if (member.TypeUsage.Facets.TryGetValue(EdmProviderManifest.StoreGeneratedPatternFacetName, false, out item))
if (member.TypeUsage.Facets.TryGetValue("StoreGeneratedPattern", false, out item))
{
var value = ((StoreGeneratedPattern)item.Value) == StoreGeneratedPattern.Computed;
}
But that's just part of the story.
What I realized is that's working in some cases (thus you need to experiment a bit) depending on what you need. But you also have other spaces in there - e.g. the SSpace. So e.g. for table names this works better...
var ssSpaceSet = objectContext.MetadataWorkspace.GetItems<EntityContainer>(DataSpace.SSpace).First()
.BaseEntitySets
.First(meta => meta.ElementType.Name == "YourTableName");
...and then private Table property.
In your case you should most info in there - but e.g. the above store generated is not populated there - but in some other 'space' I guess (more in one of the links on that).
And take a look at the following links:
Get Model schema to programmatically create database using a provider that doesn't support CreateDatabase
How I can read EF DbContext metadata programmatically?
How check by unit test that properties mark as computed in ORM model?
I am mapping quite a few WCF Data Contracts to Entity Framework Classes.
For every class I have to do this kind of thing:
Mapper.CreateMap<MyContractClass, MyDalClass>()
.ForMember(x => x.EntityKey, opt => opt.Ignore())
.ForMember(x => x.SomeAssociation, opt => opt.Ignore())
.ForMember(x => x.SomeAssociationReference, opt=> opt.Ignore())
// Repeat
// the
// last
// /two
// lines
// for
// every
// single
// association
// (Some classes have a lot of associations)
;
Is there an easier way? Some way to rule out all the extra stuff put in by EntityFramework?
Or does this just have to be done by hand?
NOTE: I have extensively evaluated the POCO template and it does not work for my scenario. Please do not just recommend that instead of Automapper.
Assuming that your contract class doesn't have the association properties, you could use this extension method to ignore them all in one statement:
Mapper.CreateMap<MyContractClass, MyDalClass>().IgnoreAllNonExisting();
I'm using T4 templates to generate the mappings from the EDMX model. This works very well and has saved me a lot of time so far. The idea is from this guy. You can download his templates and customize them to work for your scenario.
You can use EntitiesToDTOs which is simpler than AutoMapper. You don't have to write the map, neither configurate it. It is all automatically generated by the tool.
I was getting an error
An object with the same key already exists in the ObjectStateManager.
The ObjectStateManager cannot track multiple objects with the same
key.
After i googled it i found IsAttachedTo extension method there:
Is is possible to check if an object is already attached to a data context in Entity Framework?
here is my code:
foreach (string s in types)
{
Subscription subscription = new Subscription { Id = Int32.Parse(s) };
if (service.repository._context.IsAttachedTo(subscription))
service.repository._context.Detach(subscription);
service.repository._context.AttachTo("Subscriptions", subscription); //error here
horse.Subscriptions.Add(subscription);
}
But when the subscription with the same key appeared in the foreach loop the extension method IsAttachedTo returning false every time, it is does not detect that there is already such entity attached. And in result i am getting the same error:
An object with the same key already exists in the ObjectStateManager.
The ObjectStateManager cannot track multiple objects with the same
key.
Why it is could be?
What can i do to fix that?
I have little code review for you because your sample code scares me.
You probably read a lot about fancy design patterns and layered architectures and you started to use them yourselves. Unfortunately you missed the main point. What the hell is this?
service.repository._context.XXX
Why do you bother with any service layer or repository layer if they don't encapsulate their logic? Why do you expose repository on the service? Nobody should know about service internal implementation? Even worse why do you expose context on the repository? That spoiled the whole point of the repository!
There are a lot of supporting rules for writing high quality object oriented code. One of this rules is called Law of Demeter. You don't have to follow each rule, you also don't have to follow rules all the time but in case of layered architecture this law is a must.
If you have three layers A -> B -> C the layer A can call methods on the layer B but it doesn't know about C and it cannot reach its methods. If it can, it is not a new layer but it is the same layer as B and the layer A doesn't need to call it through B, it can call it directly.
In your example you have just exposed D to A because A is current layer, B is service, C is repository and D is context.
One more points about your code. There are well known naming conventions. These conventions are not about I like this and you like that but about the fact that framework you are using follow these conventions strictly so using another one to mix your naming convention with framework naming convention make your code look messy.
I'm sorry, If this was only some example code to make your code structuring clear. I just needed to describe how wrong this code is.
Now to your real problem. The method you have referenced from the related question will not work in your case. I think it will work only if you load the subscription from the database. The reason is that the referenced method uses EntityKey (either internally or directly) to get the entity from context but your new entity doesn't have the entity key yet. I expect that calling TryGetObjectStateEntry for your entity will always return Detached. Entity key it is created during attaching or you have to build it manually.
If you want some IsAttachedTo method try this:
public bool IsAttachedTo<T>(this ObjectContext context, T entity) where T : IEntity
{
return context.GetObjectStateEntries(~EntityState.Detached)
.Where(e => !e.IsRelationship)
.Select(e => e.Entity)
.OfType<T>()
.Any(e => e.Id == entity.Id);
}
And make sure that your entity implements helper interface
public interface IEntity
{
int Id { get; }
}
But to be able to detach attached entity you will need:
public T GetAttached<T>(this ObjectContext context, T entity) where T : IEntity
{
return context.GetObjectStateEntries(~EntityState.Detached)
.Where(e => !e.IsRelationship)
.Select(e => e.Entity)
.OfType<T>()
.SingleOrDefault(e => e.Id == entity.Id);
}
You will have to detach instance returned from this method.
Anyway I would start to think why do you need that for the first place because it looks like your architecture has another wrong concept. Why don't you use attached entities directly? If you don't use them why do you even keep the context with them?
It's likely that IsAttachedTo does not compare by the key (Id) but by object identity. Because you create a new Subscription for every item in the loop the objects are all different instances.
Since you seem to have objects with same Id in your types collection but in the end only want to add one object per key into the context you can perhaps make your life easier by filtering out the duplicates in the first place:
var distinctTypes = types.Distinct();
foreach (string s in distinctTypes)
{
Subscription subscription = new Subscription { Id = Int32.Parse(s) };
service.repository._context.AttachTo("Subscriptions", subscription);
horse.Subscriptions.Add(subscription);
}
This way there should be only one object per key which gets attached to the context.
We have two Assemblies that contain their own Entity-Framework EDMX & repositoriy objects. These are registered using Autofac in an ASP.NET webapplication.
These Assemblies are very similar of architecture (but differing EDMX) we have found that the last EntityConnection being registered is the EntityConnection that is being used in both Assemblies. We need to limit the usage of an EntityConnection to only be used by Types of an assembly or namespace.
var assembly = typeof(Activity).Assembly;
builder.RegisterAssemblyTypes(assembly).AsImplementedInterfaces();
builder.Register(reg => new EntityConnection(ConnectionString));
var assembly = typeof(User).Assembly;
builder.RegisterAssemblyTypes(assembly).AsImplementedInterfaces();
builder.Register(reg => new EntityConnection(ConnectionString));
Is there a way to register the EntityConnection and limit the depth of EntityConnection? Limit each EntityConnection to the assembly it belong to?
Here's a pseudocode example of how we want to register EntityConnection for use in only an assembly or namespace.
builder.Register(reg => new EntityConnection(ConnectionString)).ForNamespace("x");
try to solve the problem at an higher level of abstraction. Since you have two separate domains (one containing the Activity entity, and one containing the User entity), it would be convenient to have this explicitly in your application design. For instance, define a factory of some kind per domain:
public interface IActivityDomainContextFactory
{
ObjectContext CreateNew();
}
public interface IPeopleDomainContextFactory
{
ObjectContext CreateNew();
}
You can now easily create an implementation for each interface, register them in the Autofac ContainerBuilder and let your services depend on one of those interfaces, instead of depending them on a EntityConnection.
In this case you of course still have a dependency on the Entity Framework itself (see here for how to abstract that away), but this makes your configuration much easier, less fragile, better performing, and your application code more maintainable.
I hope this helps.
You probably want to name/key your registrations. See TypedNamedAndKeyedServices - Autofac
I think this solves half your problem, how to register the types. The other half is in the resolution. Since your doing autoregistration via assembly scanning, this might take a little more trickery.
There are plenty of good suggestions out there on improving this, so just recording my solution as a general sketch of how you'd do this in Autofac.
The trick is to use named services for the connections, then customise parameter resolution for types in each assembly so that the EntityConnection parameters get a named instance:
builder.Register(reg => new EntityConnection(ConnectionString))
.Named<EntityConnection>("activities");
builder.RegisterAssemblyTypes(typeof(Activity).Assembly)
.AsImplementedInterfaces()
.WithParameter(
(pi, c) => pi.ParameterType == typeof(EntityConnection),
(pi, c) => c.ResolveNamed<EntityConnection>("activities"));
builder.Register(reg => new EntityConnection(ConnectionString))
.Named<EntityConnection>("users");
builder.RegisterAssemblyTypes(typeof(User).Assembly)
.AsImplementedInterfaces()
.WithParameter(
(pi, c) => pi.ParameterType == typeof(EntityConnection),
(pi, c) => c.ResolveNamed<EntityConnection>("users"));