I've added insert/update methods to the domain service class.
They start with the appropriate words Insert/Update and are marked with the correspondent attributes.
Yet, they fail to get generated at the client-side so they are unavailable
from the domain context.
Is it a bug, a known by-design feature, or am I missing something?
Thanks in advance
These methods are not exposed on the client side. They are used when SubmitChanges() is called to insert, update and delete entities in the entity collection. You can add and update entities in the entity collection and they will be marked as changed or added. Then when SubmitChanges() is called, your server side code will be used.
I found this article helpful:
How SubmitChanges works in .NET RIA Servies
Related
I am building a web application in .NET Core following the Clean Architecture. I have an use case class for creating an user. Each user has a role which is passed in as an id. The use case will call to the User Repository for creating the user.
Currently, I am using FluentValidation for validating the request object. It is just pure checking such as length, not empty, etc..
My problem is that I don't know where to put the validation logic for validating the existence of the provided role. The validator is currently in the Application layer. I am going with putting the validation logic in the User repository but that doesn't sound right to me.
Do you have any ideas?
Thank you in advance.
You should add it in the validator using Fluent Validation. There are options to make custom validator and to make them async with Fluent Validation.
Creating a method in the repository for checking for the role is not necessarily wrong. But it should defently be called in validation layer along with other checks like not empty etc. etc.
For performance sake make sure that you call the check once all the other validations have passed.
I have a symfony 2 application where I set up a kernel.request listener to perform dynamic url checking by loading a corresponding entity from db.
The entity that is loaded then gets attached to a service, so that throughout the application who ever needs that data can ask the service for it.
Reviewing the code I was tempted to simply attach the entity to the Request object. It kind of makes sense, since this entity is used everywhere in the application, and it's determined by a url component.
Is that a proper way to use the Request, or is it better to leave it incapsulated into a service?
Thanks in advance
sergio
In reading an article on N-Tiered Applications, I came across information regarding concurrency tokens and change tracking information:
Another important concept to understand is that while the
default-generated entities support serialization, their
change-tracking information is stored in the ObjectStateManager (a
part of the ObjectContext), which does not support serialization.
My question is three-fold:
Is there the same thing when using DbContext?
If the only interaction with the database is in a Repository class within a using statement, does closing the database connection when the program leaves the using statement get rid of any option for change tracking?
Can this be leveraged as/with a Concurrency Token?
Yes. DbContext is just wrapper around ObjectContext and it exposes change tracking information through ChangeTracker property (returns DbChangeTracker) and for particular entity through calling Entry method (returns DbEntityEntry<T>).
Yes. Closing context will remove all change tracking information.
Concurrency token and change tracking are two completely different concepts. Change tracking tells context what operations it has to execute on database when you call SaveChanges. It tracks changes you did on your entities since you loaded them into current context instance. Concurrency token resolves optimistic concurrency in the database => it validates that another process / thread / user / context instance didn't change the same record your context is going to modify during SaveChanges.
I'm working with a project in ASP.Net using Webforms. I'm using Entity Framework to save data on Microsoft SQL.
My question is:
Is possible to use a Static class to keep the ObjectContext of EF live and put/get entities NOT saved inside the ObjectContext?
I want to create an Object, then added with AddObject on the ObjectContext, But NOT to do the Savechanges. All this in one webform. And then, in other webform, access to the ObjectContext and get the Object when added.
It is this possible?
My rules to using ObjectContext:
Do not use static context.
Do not share context.
You are trying to violate both rules. If you do that your application will have undeterministic behavior. Create new ObjectContext instance for each request. It is the same as openning new connection and starting new transaction in the request instead of sharing one connection and one transaction among all of them.
Further explanation also here. Also check linked question in right column and you will see what type of problems people have just because of violating one or both mentioned rules.
Also in web application it becames even more interesting because ObjectContext is not thread safe.
You could add it to the application items collection. See this blog post for syntax and such.
http://www.informit.com/articles/article.aspx?p=27315&seqNum=3
Generally, you don't want to. An ObjectContext is intended to be a unit of work, alive for a single set of related transactions. In an ASP.NET application, that generally corresponds to a single request.
If you must keep it alive for multiple requests, I wouldn't use either a static class, nor the application context. Instead, I'd recommend using the Cache, and then attaching the callbacks to it that let you ensure all your transactions are committed before it gets evicted, just in case.
I have a problem with WCF seemingly not including attributes such as Category when passing entities around.
I have a class wrapped around an EF entity, used to populate a property grid on a thick client.
I am trying to retrieve information from the server, using WCF, and to replicate the property grid on the client side. I have tested the code, and in the host, I am able to determine the category of the elements in the instance.
When I request an instance from an ASP.NET site, however, it seems that I cannot retrieve the category information. All I get is, Misc, so I assume that means when I serialize it, the attributes get stripped.
Information specific to .NET is not passed in metadata. Therefore, the information is not used in creating the proxy classes that you create using svcutil or "Add Service Reference". This is why attributes, or non-default constructors, or methods, or indexers, do not appear in proxy classes.
You should try to do without this sort of information. However, if you really need it, you can put those types into a separate assembly, and share it with the client. This will mean that you have to update all of your clients when you update that assembly.