I have in the ViewModel an ObservableCollection<INode> where INode is an interface.
The View XAML is like:
<Windows x:Class="XXX.Window1"
xmlns:vw="clr-namespace:XXX.Views"
xmlns:vm="clr-namespace:XXX.ViewModels"
xmlns:n="clr-namespace:XXX.Models.Nodes"
... />
...
<vm:MyView>
<vw:MyView.DataContext>
<vm:MyViewModel>
<vm:ComponentViewModel.Nodes>
<n:MyNode /> <--- PROBLEM HERE
<n:MyNode />
</vm:ComponentViewModel.Nodes>
</vm:MyViewModel>
</vw:MyView.DataContext>
</vm:MyView>
...
Now this works at runtime, but not in the design time window which shows:
Could not create an instance of type 'MyNode'
Any idea how to solve this?
interface INode
{
string Name { get; set; }
string Status { get; }
}
abstract class Node : INode
{
public string Name { get; set; }
public abstract string Status { get; }
public override int GetHashCode()
{
unchecked
{
return Name.GetHashCode(); // <--- PROBLEM WAS HERE, Name = null
}
}
}
class MyNode : Node
{
public override NodeStatus Status { get { return "test"; } }
}
Each case seem to be unique. Here's what I learned after solving it: Not only an exception in the constructor can generate that error message. If some system methods like GetHashCode() throw and exception, it'll display that same message (some times at design-time only).
Other people may have more tips or more insight VS design-time flow.
As far as I can see it is not a XAML problem, but happens because you are not setting the Name property. When GetHashCode is called it will fail because you are calling a method on a null reference.
Try adding your node as
<n:MyNode Name="blah" />
Related
In addition to my original post I guess I need to mention that I am using Prism 6.3. Apparently, the compiler doesn't like stuff added to the metadata class that's not in the original partial. Not sure how to resolve this.
Thanks again ... Ed
Ok, I give, UNCLE!
I am trying to add data annotations to my wpf entity framework app. I've tried 6 ways to Sunday with no luck. I put together what is what I consider the most simple example possible and followed all the instructions ... nothing works.
Here goes.
I have a class that is generated by EF (db first).
namespace junk.DataModels
{
public partial class MyClass
{
public string SomeText { get; set; }
}
}
I have another file with the following partial class:
namespace junk.DataModels
{
[MetadataType(typeof(MyClassMetaData))]
public partial class MyClass
{
}
public partial class MyClassMetaData
{
private string _someText;
[Required(ErrorMessage = "Required")]
public string SomeText
{
get { return _someText; }
set { SetProperty(ref _someText, value); }
}
}
}
In my ViewModel I define:
private MyClass _mc;
public MyClass MC
{
get { return _mc; }
set
{
SetProperty(ref _mc, value);
}
}
And in the constructor:
MC = new MC();
MC.SomeText = "Hello World.";
Lastly, in my xaml:
I have a single bound control:
<TextBox x:Name="txt" Text="{Binding MC.SomeText,
ValidatesOnDataErrors=True,
ValidatesOnExceptions=True,
ValidatesOnNotifyDataErrors=True,
UpdateSourceTrigger=PropertyChanged }"
/>
According to everything I've read, if I run this and clear the textbox, I should get a validation error. I have tried all combinations of "ValidatesOn" it doesn't seem to make a difference. Can someone take pity on me and share the secret sauce? I must be missing something simple. If I bind to the metadataclass it works but that is kinda defeating the purpose.
Any help would be great!
Try adding the following static constructor to your buddy class "MyClass". It will register the metadata against your EF class so the Validator can find the Data Annotations:
static MyClass()
{
// Register the metadata against our EF data object.
// This will ensure the Validator find the annotations
TypeDescriptor.AddProviderTransparent(
new AssociatedMetadataTypeTypeDescriptionProvider(
typeof(MyClass),
typeof(MyClassMetaData)),
typeof(MyClass)
);
}
You could also try running a unit test to confirm whether the Validator has used your annotation, before adding the complexity of the GUI:
[TestMethod]
public void TestAnnotations()
{
MyClass c = new MyClass();
// Manually validate the MyClass object
List<ValidationResult> validationResults = new List<ValidationResult>();
ValidationContext context = new ValidationContext(c, serviceProvider: null, items: null);
bool isValid = Validator.TryValidateObject(c, context, validationResults, validateAllProperties: true);
Assert.IsFalse(isValid, "Validation should fail because we didn't set SomeText");
}
This is one of the class definitions within a DLL I use in my WCF service.
[DataContract]
public class ScenarioXML
{
[DataMember(Order = 1)]
public long? TNRScenario { get; set; }
[DataMember(Order = 2)]
public long? TNRProject { get; set; }
[DataMember(Order = 3)]
public int? Priority { get; set; }
// ...
[DataMember(Order = 19)]
public List<ScenarioAssetXML> ScenarioAssets { get; set; }
[DataMember(Order = 20)]
public List<CalendarXML> Calendars { get; set; }
[DataMember(Order = 21)]
public ScenarioTriggerCollectionXML ScenarioTriggerCollection { get; set; }
}
I'm using DataContract instead of ProtoContract, so I can expose this class to a Silverlight project through a WSDL, and still use Protobuf-net for serialization.
Now, when I use the following code in my WCF service, the original "scenario" and the "restoredModel" are identical.
MemoryStream msTestString = new MemoryStream();
Serializer.Serialize<ScenarioXML>(msTestString, scenario);
string memento = Convert.ToBase64String(msTestString.ToArray());
byte[] byteAfter64 = Convert.FromBase64String(memento);
MemoryStream afterStream = new MemoryStream(byteAfter64);
ScenarioXML restoredModel = Serializer.Deserialize<ScenarioXML>(afterStream);
However, when I use the same code in Silverlight, the TNRScenario value is null.
Similarly, the TNRScenarioAsset property of the objects in the ScenarioAssets list are null.
[DataContract]
public class ScenarioAssetXML
{
[DataMember(Order = 1)]
public long? TNRScenarioAsset { get; set; }
[DataMember(Order = 2)]
public long? TNRScenario { get; set; }
[DataMember(Order = 3)]
public string Asset { get; set; }
[DataMember(Order = 4)]
public string Action { get; set; }
}
When I make the first property a string, it completely vanishes after (de)serialization. When I put a dummy bool as a first property, the bool is there, but the second property, in this case ScenarioAssets, is still null. There's something weird going on here...
Am I doing somethign wrong, or is this a bug?
Edit:
You're right Marc! The orders get messed up in the WSDL-generated code.
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "4.0.0.0")]
[System.Runtime.Serialization.DataContractAttribute(Name="ScenarioXML", Namespace="http://schemas.datacontract.org/2004/07/DataCollectionDLL")]
public partial class ScenarioXML : object, System.ComponentModel.INotifyPropertyChanged {
private System.Nullable<long> TNRScenarioField;
private System.Nullable<long> TNRProjectField;
private System.Nullable<int> PriorityField;
//...
[System.Runtime.Serialization.DataMemberAttribute()]
public System.Nullable<long> TNRScenario {
get {
return this.TNRScenarioField;
}
set {
if ((this.TNRScenarioField.Equals(value) != true)) {
this.TNRScenarioField = value;
this.RaisePropertyChanged("TNRScenario");
}
}
}
[System.Runtime.Serialization.DataMemberAttribute(Order=1)]
public System.Nullable<long> TNRProject {
get {
return this.TNRProjectField;
}
set {
if ((this.TNRProjectField.Equals(value) != true)) {
this.TNRProjectField = value;
this.RaisePropertyChanged("TNRProject");
}
}
}
[System.Runtime.Serialization.DataMemberAttribute(Order=2)]
public System.Nullable<int> Priority {
get {
return this.PriorityField;
}
set {
if ((this.PriorityField.Equals(value) != true)) {
this.PriorityField = value;
this.RaisePropertyChanged("Priority");
}
}
}
//...
However, I'm not sure how to correctly implement that partial class? I created it in the WCF service, but that seems to confuse the compiler. Getting the following errors:
Error 6 'DataCollectionDLL.ScenarioXML' does not contain a definition for 'TNRScenario' and no extension method 'TNRScenario' accepting a first argument of type 'DataCollectionDLL.ScenarioXML' could be found (are you missing a using directive or an assembly reference?)
Error 2 Cannot convert type 'DataCollectionDLL.ScenarioXML [c:\Projects\Flowcontrol 1.7.1.1\flowcontrolFC.Web\Libraries\DataCollectionDLL.dll]' to 'DataCollectionDLL.ScenarioXML [C:\Projects\Flowcontrol 1.7.1.1\flowcontrolFC.Web\DAL\DataCollectionClasses\ScenarioXML.cs(31)]'
Then tried it in the Silverlight project, which compiles fine but that doesn't solve the problem. Results are the same.
The partial class I created:
namespace DataCollectionDLL
{
[ProtoContract]
[ProtoPartialMember(1, "TNRScenario")]
[ProtoPartialMember(2, "TNRProject")]
[ProtoPartialMember(3, "Priority")]
//...
[ProtoPartialMember(21, "ScenarioTriggerCollection")]
partial class ScenarioXML
{
}
}
It sounds like you used WSDL-generated proxies; that can confuse things a little bit, because protobuf-net really really cares what the numbers are, and WSDL can sometimes play fast and loose with those. It would really help if I could see the WSDL-generated proxy classes (in the .designer.cs), but I'm going to assume this is the problem. Fortunately, most code-generators use partial class, so you can add your own partial class in a separate file to add extra information into the same type, in particular: more attributes. For example:
namespace The.Same.Namespace
{
[ProtoContract]
[ProtoPartialMember(1, "TNRScenario")]
[ProtoPartialMember(2, "TNRProject")]
// ...
[ProtoPartialMember(21, "ScenarioTriggerCollection")]
partial class ScenarioXML { }
}
This will get merged by the compiler into the ScenarioXML class, and should allow protobuf-net to use the correct numeric identifiers for each property.
I am sending some simple user details to a Nancy module. I am taking advantage of Nancy's model binding feature to harvest the user details from the request and pass them to my UserService.Add(...) method, like this:
Nancy Module
Post["/add"] = parameters =>
{
var user = this.Bind<UserDetails>();
UserService.Add(user);
return HttpStatusCode.OK;
};
User Details Class
public class UserDetails
{
public string UserName { get; set; }
public string Password { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string Email { get; set; }
}
User Service
public static void Add(UserDetails user)
{
//Add the user
}
This works and makes for terse syntax in the Nancy Module. However it means that I am forced to create a data-transfer (DTO) class simply to harvest the Request payload.
Is it possible to avoid this intermediary class altogether? Instead of binding a class to the payload, would it be possible to bind the Method parameters instead?
This would give code that might look something like this:
Nancy Module
Post["/add"] = parameters =>
{
this.BindAndCall<UserService>("Add");
return HttpStatusCode.OK;
};
User Service
public static void Add(string firstName, string lastName, string email, string userName, string password)
{
//Add the user
}
You can always create some extension methods or custom binder, but then you are coupling the internal implementation of your service to the exact naming of the parameters for the payload, which is not good, as later when your service changes, you need to change the payload or jump trough hoops. There's nothing wrong with the DTO, it costs nothing to create.
The ParameterBag - A Partial Solution to DTO Proliferation
To my mind, DTOs are pain as they tend to proliferate into a shadow-domain. This creates headaches when you decide to reorganise your service layer.
So why not just use dynamic types and forget all about DTOs and strongly-typed route parameters? Well dynamic values are very convenient but they have their own problems, chiefly that you cannot pass them to extension methods. So it is just easier to have the route parameters correctly presented, hence model binding, hence DTOs and hence spaghetti and silly hats.
So here is a partial solution relies on Nancy's Model Binding. It significantly reduces route-level ceremony and helps contain that annoying DTO proliferation.
Nancy Base Module
public class _BaseModule : NancyModule
{
public class ParameterBag
{
// All the params used across all routes, GET and POST
public string UserName { get { return this.Value; } }
public string UserIds { get; set; }
public string UserId { get; set; }
public string Value { get; set; }
public int Skip { get; set; }
public int Take { get; set; }
}
public ParameterBag Params;
public _BaseModule(): this(""){}
public _BaseModule(string modulePath): base(modulePath)
{
Before += ctx =>
{
this.Params = this.Bind<ParameterBag>();
return null;
};
}
}
The ParameterBag class contains all the parameters that I am interested in binding across all routes. Since Nancy will only populate the properties if it finds a matching field in the payload, you can just add as many properties to this class as you like without caring if they will be used by a given route or not.
Note how the Binding takes place in the Before hook. This means that every route (that derives from the _BaseModule) will automatically bind any matching parameter values to the universal ParameterBag class properties. No specific route-level intervention required.
The effect of this is to provide the route handlers with a strongly typed parameter values that can be just used.
Nancy Module
public class UserModule : _BaseModule
{
public UserModule()
{
// handlers go here
}
}
Route Handler Example
Get["/user/{userid}/username/available"] = _ =>
{
return Response.AsJson(new
{
// the username is a hidden value
// the userid comes from the url
value = Params.UserName,
valid = UserService.UserNameAvailable(Params.UserName, Params.UserId)
}
);
};
Example Usage
The example below relies on the jqBootstrapValidation. It shows how the Binding trick works for parameter data supplied on the URL and provided as part of an ajax payload (see value attribute).
<input
type="text"
id="username"
name="username"
placeholder="User Name"
data-validation-ajax-ajax="/user/#user.id/username/available"
data-validation-ajax-message="This name has already been taken"
value="#user.UserName"
required>
I am having problems databinding to EF code first. I need to be using Eager Loading, but I am running into some issues with databinding. I have the following classes:
public class Context : DbContext
{
DbSet<A> As;
DbSet<B> Bs;
DbSet<C> Cs;
}
public class A
{
public ICollection<B> Bs { get; set; }
public string Name { get; set; }
}
public class B
{
public ICollection<C> Cs { get; set; }
public string Name { get; set; }
}
public class C
{
public string Name { get; set; }
}
I am data binding Context.As to a Treeview, using the below code:
Context.As.Load();
tvItems.ItemsSource = Context.As.Local;
This works as expected, however, it does not automatically load the child properties, Bs, and subsequently, Cs. So, I found that lazy loading can help with this, like so:
Context.As.Load();
tvItems.ItemsSource = Context.As.Include(u=>u.Bs);
From my reading, this should automatically load at least the first level of child properties. However, this will not data bind, as I did not use .Local
.Include() returns IQueryable, which does not support .Local. I can use .ToList(), but this will not automatically update when I add items.
So, how the hell am I supposed to be doing this?
You could try this:
Context.As.Include(a => a.Bs).Load();
tvItems.ItemsSource = Context.As.Local;
I'm currently trying to create a small application using the MVVM pattern. However I don't really know how to correctly wrap up aggregated Model classes in my ViewModel. From what little I know about MVVM, you're not supposed to expose Models in your ViewModel as properties or else you could directly bind to the Model from your View. So it seems I have to wrap the nested Model in another ViewModel, but this imposes some problems while synching Model and ViewModel later on.
So how do you do that efficiently?
I'll give a short example. Let's suppose I have the following model classes:
public class Bar
{
public string Name { get; set; }
}
public class Foo
{
public Bar NestedBar { get; set; }
}
Now I create two ViewModel classes accordingly, wrapping the Models, but run into problems with the FooViewModel:
public class BarViewModel
{
private Bar _bar;
public string Name
{
get { return _bar.Name; }
set { _bar.Name = value; }
}
}
public class FooViewModel
{
private Foo _foo;
public BarViewModel Bar
{
get { return ???; }
set { ??? = value; }
}
}
Now what do I do with the Bar-property of FooViewModel? For "get" to work I need to return a BarViewModel instance. Do I create a new field of that type in FooViewModel and just wrap the _foo.NestedBar object in there? Changes to that field's properties should propagate down to the underlying Bar instance, right?
What if I need to assign another BarViewModel instance to that property, like so:
foo.Bar = new BarViewModel();
Now that won't propagate down to the model, which still holds the old instance of type Bar. I'd need to create a new Bar object based on the new BarViewModel and assing it to _foo, but how do you do that elegantly? It's pretty trivial in this sample, but if Bar is much more complex with lots of properties, that'll be a lot of typing... not to mention it'd be very prone to errors, if you forget to set one of the properties.
#Goblin
There are some flaws with your code: e.g. what if I get a list of Foo objects from database and I want to wrap each of them in an ObservableCollection?
then your Constructor of FooViewModel should accept the Foo model as parameter and not create it inside the Constructor!
Normally you do this to wrap a model into a viewmodel and put it the same time into a bindable Collection:
IEnumerable<Foo> foos = fooRepository.GetFoos();
foos.Select( m => viewmodelCollection.Add(new ViewModel(m,e.g.Service)));
The models properties are not copied to the ViewModel hell no!!! The ViewModel does delegate its properties to the model properties like:
public class FooViewModel
{
private Foo _foo;
public FooViewModel(Foo foo,IService service)
{
_foo = foo;
}
public string FoosName
{
get{return _foo.Name };
set
{
if(_foo.Name == value)
return;
_foo.Name = value;
this.NotifyPropertyChanged("FoosName");
}
}
}
And like Goblin said all UI-Specific interfaces like:
IDataErrorInfo
INotifyPropertyChanged
IEditableObject
etc...
are implemented the by the ViewModel ONLY.
My above answer only makes sense if you are doing DDD - if you are not - you can solve your problem like this - simply 'flattening' the model:
public class FooViewModel
{
private Foo _foo;
public string Name
{
get { return _foo.Name; }
set { _foo.Name = value; }
}
public string BarProperty
{
get { return _foo.Bar.Property; }
set { _foo.Bar.Property = value; }
}
}
Or you could do like I showed in the prior example - just ignore everything about Aggregates... should still work.
Okay - first things first - using the term Aggregate implies you are adhering to DDD? If you are - you are doing an encapsulation no-no :-). One Aggregate should never be allowed to edit another Aggregate. If what you have is that both are really Aggregate they would become associated (which is perfectly 'legal' in a DDD-sense - but then your propety on the FooViewModel wouldn't be of type BarViewModel, but rather type Bar. That way Bar would (as it should) be responsible for updating itself - and we only maintain the link in FooViewModel.
However, if what you are doing is AggregateRoot with a ValueType child - then here is what you could do given a slightly modified domain model:
public class Foo
{
public string SomeProperty { get; set; }
public Bar Bar { get; set; }
public void Save()
{
//Magically saves to persistent storage...
}
}
public class Bar
{
public Bar(string someOtherProperty)
{
SomeOtherProperty = someOtherProperty;
}
public string SomeOtherProperty { get; private set; }
}
And then for the ViewModels:
public class FooViewModel
{
private Foo _foo;
public FooViewModel()
{
Bar = new BarViewModel();
}
public BarViewModel Bar { get; private set; }
public void SetFoo(Foo foo)
{
_foo = foo;
SomeProperty = foo.SomeProperty;
Bar.SetBar(foo.Bar);
}
public string SomeProperty { get; set; }
public void SaveChanges()
{
_foo.SomeProperty = SomeProperty;
_foo.Bar = Bar.CreateUpdatedBar();
_foo.Save();
}
}
public class BarViewModel
{
public string SomeOtherProperty { get; set; }
public void SetBar(Bar bar)
{
SomeOtherProperty = bar.SomeOtherProperty;
}
public Bar CreateUpdatedBar()
{
return new Bar(SomeOtherProperty);
}
}
This way - the FooViewModel is now capable of controlling the BarViewModel (which does nothing but accept a valuetype - and create a new one when asked). This also solves a common UI-problem ('How do we edit an object that has no setters?' - answer: 'We don't - we create a new one'). A lot of fleshing out is missing (INotifyPropertyChanged, dirty-tracking etc., but those are easy if you get through this leap of thinking :-).
I hope this makes a wee bit of sense :-) Otherwise, I'll be happy to elaborate.