Good Morning,
I'm trying to beat an end of year deadline and running into the error in the screenshot. I've been through my WF service several times to no avail. One thing that I think has meaning but I 'm not able to make the connection is how Response is added to the end of the Receive OperationName.
As mentioned above note how the error has Response added right to the end of the OperationName. It seems significant but I can't figure out why.
Also note the Content message of the Receive and SendReplyToReceive has a message type of null. (I'm going with the fact that it is inferred).
Code for the RequestDataContract
[DataContract]
public class LiftDataExchangeRequest
{
//pretty simple we only have one thing we want from the client in request
[DataMember]
public String UserName{ get; set; }
[DataMember]
public String Password{ get; set; }
[DataMember]
public ExchangeEnumerations Action { get; set; }
}
Code for the Response:
public class LiftDataExchangeResponse
{
public XmlDocument WorkoutData { get; set; }
}
I'll gladly post anything else needed to help track this down and I would be very grateful to any additional information or reading.
The error you're seeing is a limitation of the visual tool you're using (WCF Test Client), it is not designed to handle all possible services - there are some types that will prevent it from working. However, there's nothing wrong with your actual service.
Related
I am struggling to find a simple answer to this question, hopefully someone out there can help?
I have a system using MVC3 code first and EF4.1.
I have a number of models and I am trying to override DbContext.SaveChanges to provide an audit facility.
There are certain high volume columns that should be excluded from the Audit.
I had hoped that I could use the AdditionalMetadata tag like so...
public class User : IAuditable
{
[Key]
public int UserID { get; set; }
public string Name { get; set; }
public string DisplayName { get; set; }
[AdditionalMetadata("IgnoreAudit", true)]
public DateTime? LastActive { get; set; }
}
and then in my audit code use something like...
bool AuditThis = ModelMetadata
.FromLambdaExpression(dbEntry.Property(propertyName), null)
.AdditionalValues("IgnoreAudit");
to determine whether to log the change or not.
Obviously this code fails as it was taken (and changed!) from a view.
My question is. Can the ModelMetaData be read outside of a ViewContext or am I barking up the wrong tree?
Thanks for taking the time to read.
I found the pointer on stackoverflow here but I needed the slightly different
var metaData = ModelMetadataProviders
.Current.GetMetadataForProperty(null, objType, propertyName);
We are at a point in our development cycle (asp.net mvc applciation), where we need to introduce changes to our existing commands and events (say adding/removing a few properties etc).
I have been trying to find a way to introduce commands/events versioning in the system. I have read many posts on google/stackoverflow etc but am still to see an example of code that implements it. Is there a recommended pattern one should follow when versioning. If yes any examples/snippets?
Edit: This is how far i have gotten with this
i have versioned my events backwards, such that the latest will always be called the same, while the ones that go obsolete will have a suffix added to it like '_V1', '_V2' etc.
So if i have an event
public class OrderSubmittedEvent : IDomainEvent
{
public int OrderId { get; private set; }
public OrderSubmittedEvent(int orderId)
{
OrderId = orderId;
}
}
and if i have to add a few properties i rename my event above to
public class OrderSubmittedEvent_V1 : IDomainEvent
{
public int OrderId { get; private set; }
public OrderSubmittedEvent_V1(int orderId)
{
OrderId = orderId;
}
}
and introduce another event with the same name as my original event but with added properties, like so
public class OrderSubmittedEvent : IDomainEvent
{
public int OrderId { get; private set; }
public OrderSubmittedEvent(int version = 1, int orderId = 0, string customerName =
"Joe blogs", string address = "Earth")
{
OrderId = orderId;
CustomerName = customerName;
Address = address;
CurrentVersion = version;
}
public static int LatestVersion
{
get { return 2; }
}
public int CurrentVersion { get; set; }
public string CustomerName { get; set; }
public string Address { get; set; }
}
i still have to go ahead and change my code which publishes this event to include values for new properties.
any given point of time when i get all my events from the event store (say, for replaying) they will always be of the same type after deserialization (in this case OrderSubmittedEvent) with new properties which were not part of the old events populated with their default values.
At the time of replaying my events i make my events go through an IEventUpgrader
This first verifies if the events is the latest version available. since the type will always be the event type, this check is based on the properties "LatestVersion" and "CurrentVersion"
what does everyone think of this approach?
next todo
If event is an old version publish an 'UpdateMYEVENT' Event
thanks
usually you only need to version the events, you can ignore the commands since you don't store them in the event store.
There are few ways to implement versioning.. my method is quite simple:
[Obsolete]
public class CompanyCreated
{
public Guid Id { get; set; }
public string Name { get; set; }
}
public class CompanyCreated_V2
{
public Guid Id { get; set; }
public string CompanyName { get; set; }
public string TaxNumber { get; set; }
}
You need to handle conversion of events from the old one to the new one as you read the events from the event store.
also, you need to be aware that you never remove any old event classes, hence why I decorate them as Obsolete, to let other developers know not to use the event.
If you are only adding & removing properties, there might be no need to version events; just ignore the serialized properties that are removed, and use sensible defaults for the ones you add.
I would be cautious with mixing events and commands. They have different purposes and solve different problems.
To give a better feeling of what I mean, think of it like so
Commands are more like RESTful API, client-server communication.
While Event Sourcing is more of a way to store the data.
Both need versioning as a way to provide backward compatibility through immutability, but once again for different reasons. Hence implementation and exceptions are different.
I would definitely recommend a book Event Versioning by Greg Young to get more insides into versioning for event sourced systems..
For more information on the commanding, check out the CQRS series and particularly CQRS via HTTP.
Admittedly I have not had the opportunity to try the following but I'd like go bake in the versioning from day one:
Since the full type name is relevant I would go for namespaces.
namespace Primary.Messages.V1
{
public class CompanyCreated
{
public Guid Id { get; set; }
public string Name { get; set; }
}
}
namespace Primary.Messages.V2
{
public class CompanyCreated
{
public Guid Id { get; set; }
public string Name { get; set; }
public string TaxNumber { get; set; }
}
}
These could be in different assemblies and you could mark the older ones as obsolete (as suggested by Sarmaad). It may be that older version are not necessarily obsolete though.
Any ideas?
I am totally out of reasons while considering why would one need event-versioning the way it has been asked in question and more specifically the way it has been suggested in the answers?
I can think of only two use cases
1- the event class currently being used is deprecated and no more needed.
Then that class can be tracked down in the git anytime needed. So why bother and complicate the active code by keeping the dead classes?
2- The business requirement is changed and now you need to keep the base event but you also need another similar event with some parameter differences.
That can be solved in a number of ways, like decorator pattern can help to handle such variations to a great extent
Alternately the new event might be representing a unique domain concept and instead of trying to force the concept into existing model, it might be better to name it more semantically and use it that way.
If you go to this website, http://www.asp.net/mvc/tutorials/getting-started-with-aspnet-mvc3/cs/intro-to-aspnet-mvc-3, you can see a tutorial where users create a movie database. I completed this tutorial with no problems, and attempted to create a new MVC application with some small changes that make the project more similar to what I want to do eventually.
Rather that create a model named Movie, I created one named Issue. Like movie, it has a few fields, but they are all different names and types. I went through the process exactly as is done in the tutorial, but whenever I try to add an issue to the database via the web UI, I get a DBEntityValidationException. I have not set any validation rules at this point in the process, so I am unsure of what the problem is.
Can someone give me some advice on fixing this so that I can add Issues to my database (as is done with movies on the online tutorial)?
Let me know if more information is needed; I am very new to this and may be lacking in details.
Here is the model code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Data.Entity;
namespace MvcApplication200.Models
{
public class Issue
{
public String id { get; set; }
public DateTime created { get; set; }
public DateTime closed { get; set; }
public String summary { get; set; }
public bool? importToTFS { get; set; }
}
public class IssueDBContext : DbContext
{
public DbSet<Issue> Issues { get; set; }
}
}
Update:I just redid the whole process, but rather than have different fields and different types, I made it so that my Issue model had the same number and same types of fields (with only different names). The error went away, so the problem must be with db format or something. I hope this makes the problem more clear.
I just ended up adding this class, which removes everything from the database when fields are changed. Then, I refresh the database, which is easy to do in my situation. One could add some items to the Seed method in order to ensure that some things remain in the updated database after it is cleared.
public class IssueInitializer : DropCreateDatabaseIfModelChanges<IssueDBContext>
{
protected override void Seed(IssueDBContext context)
{
//add things here
}
}
I'm building a forum project for ASP.NET MVC 3, running on .NET 4 with the latest version of Entity Framework.
I have the usual forum design, with a Board with Categories, and Categories with Forums, Forums with Topics and Topics with Posts etc.
Simplified:
public class Category {
[Required]
public virtual Board Board { get; set; }
}
public class Forum {
[Required]
public virtual Category Category { get; set; }
}
public class Topic {
[Required]
public virtual Forum Forum { get; set; }
}
public class Post {
[Required]
public virtual Topic Topic { get; set; }
}
When a new post is created the topic is informed, and when a topic is changed, the forum is informed.
So, again simplified:
public class Forum {
public void TopicChanged(Topic topic) {
// Do stuff
}
}
public class Topic {
public void PostAdded(Post post) {
// Do stuff
this.Forum.TopicChanged(this);
}
}
So after creating a new Post (and committing it to the database), I call PostAdded on the parent topic. Now this is where it get odd!
When I commit the changes to my repositories, I get a validation error, Category on Forum is required.
If I look in the database, the Forum has a reference to the parent Category. If I stop the code and looks at the Forum object, it has a Category instance. So this looks like an issue with lazy loading, especially because if I add this line:
var cat = this.Category
At the bottom of the TopicChanged method in the Forum class, there's no longer any errors.
Am I doing something totally wrong here, have I run into a borderline issue, or what is going on? I figured EF would see that the reference is a lazy loaded reference, and if it hasn't been changed, there's no reason why this should fail on save???
Thanks,
Steen
I've fixed my problem. It might not be a really nice and clean solution, but at least I can handle this situation now, without having to change a lot of my code (which needs to run with nHibernate also). So no dirty solution.
Just to give you an idea on how it's solved, I'll try and explain it here.
On the Commit() method on my repository, I start off calling GetValidationErrors() on the DbContext instance. This returns the error I encountered above along with the entity where the error occurs. On the base type of this entity (the entity is a proxy generated by EF) I run through all properties and when I encounter a property with the Required attribute, I call GetValue on the identical property on the proxy object.
Enough talk, more code:
var errors = this.context.GetValidationErrors();
foreach (DbEntityValidationResult result in errors) {
Type baseType = result.Entry.Entity.GetType().BaseType;
foreach (PropertyInfo property in result.Entry.Entity.GetType().GetProperties()) {
if (baseType.GetProperty(property.Name).GetCustomAttributes(typeof(RequiredAttribute), true).Any()) {
property.GetValue(result.Entry.Entity, null);
}
}
}
Greetings all,
I have researched and found a number of discussions on designing a MVC service layer, but I haven't found an answer to my exact questions. The post on service layer interdependency has an image illustrating what I have in mind, but I have a further question that I don't believe is covered in the referenced post.
My application will track data for a non-profit that interacts with humans in multiple contexts. Maybe the human was a client, maybe they were an adviser, or maybe they were an adversary. They can be multiple. A client may later become an adversary (think lawyers' clients).
My idea is that the creation of a new client or a new adversary always creates two records: 1 record in the person table and one record in the ancillary table. My thoughts behind this is that there will be one place (the person table) to check to see if the business has had any past interaction with a given person.
My question is , when representing entities in a 1 to 0..1 relationship to the controller layer, (1) Should the controller be involved in combining and splitting classes before passing them to a view? (2) If not, should the service layer construct the viewmodel?
I've read the post about the 1800 line Controller here.
I've also read this post that says your service layer shouldn't know about the view model, which makes me think it lives and dies in the controller layer. If the service layer doesn't touch the viewmodel, for example, (3) is it good design for the workerService to return both Person and Worker objects to the Controller?
Here are my entity classes:
public class Record
{
public DateTime datecreated { get; set; }
public DateTime dateupdated { get; set; }
public string Createdby { get; set; }
public string Updatedby { get; set; }
}
public class Person : Record
{
public int ID { get; set; }
public virtual Worker Worker { get; set; }
publiv virtual Defendant defendant {get; set;}
...
}
public class Worker : Record
{
public int ID { get; set; }
public virtual Person person { get; set; }
...
}
public class Defendant : Record
{
public int ID { get; set; }
public virtual Person person { get; set; }
...
}
I think you should try and find a balance between whats "good design" and what works for you.
For instance, I have an MVC application that uses ASP.NET Membership, but I also have a custom User table, where I store things like a user's fiendly name, or OpenID. In that same application I have an IAdminService that handles everything concerning user administration.
What IAdminService returns to the controller is an AdminUser class, which looks like:
public class AdminUser
{
public string UserName { get; set; }
public User User { get; set; }
public MembershipUserWrapper MembershipUser { get; set; }
}
MembershipUserWrapper is just a wrapper around the default MembershipUser to allow for testing and more flexibility in general.
Anyway, you could argue that AdminUser is actually a view model and indeed I do have a couple of views strongly typed to AdminUser. It would be complicating matters unnecessarily to not let IAdminService return an AdminUser just because it is in the "service layer", and in this case, you don't want the controller performing the "transformation" from User and MembershipUserWrapper to AdminUser every time.
is it good design for the workerService to return both Person and Worker objects to the Controller?
I think in this case it probably is. You could have two separate services, but most of the logic for fetching a Worker and a Person is probably the same, so you'd be forcing yourself to either repeat a lot of code or create a third service that performs the common tasks.
You should pay attention to proper desing, but take also K.I.S.S. and YAGNI into account. Do what makes sense now, and refactor accordingly whenever needed.