Set a Parent property on Child Objects when binding - asp.net-mvc-3

We have a hierarchical model of the shape (yuml-ized):
And a controller action that takes an Order-typed parameter:
public ActionResult UpdateOrder(Order order)
{
...
}
With the posted form having fields for the line items, too, we get a tree of objects from the MVC's model binding where as the binders create a new order object for each order to be bound.
The question: Is it possible to have the binding mechanism set the Parent property of each LineItem to the Order object they are being added too?
I take it that the binder that binds the Order object is responsible for executing a binder for each child object, too, by calling BindModel on the child object binders. We already have custom implementations (inheriting from DefaultModelBinder) in place: A OrderBinder as well as a LineItem binder.
How can our LineItem.BindModel method find out whether the LineItem being bound is "stand-alone" or about to be added to an Order whose binding is in progress, and if the latter is the case, how do we get the reference to that Order?

Related

instantiating a domain object from form input

In DDD, your domain object's properties are mostly readonly from the outside. Now, in MVC, you'll typically get the object provided to you from the view or repository, but how do you go about this in Webforms, where you read the form inputs manually and apply them to the domain object? Do you create a DTO and give the domain object a Create method that takes the DTO?
The common pattern for recording an action or activity in a domain model, is to model the action as an object associated with the thing, people and places it interacts with.
So by example, if one had Orders associated with a Product, one would typically create the Order via an Order method on the applicable product. Data representing the Order captured via the UI would be passed to that Order method.
This represents the simple case for illustration purposes.
Do you create a DTO and give the domain object a Create method that takes the DTO?
No, you will typically have a piece in the middle, a message handler which is responsible for taking the DTO and converting it to values recognized by the domain. The domain objects have command methods that are used to update the state of the model.
So something like
Receive the DTO
Lookup the appropriate handler for that DTO
Parse the DTO, creating the value types recognized by the domain
Load the target aggregate from the repository
Invoke the command on the target, passing domain value types as arguments.
"Input validation" typically happens in step 3. "Business validation" typically happens on step 5.
A good approach is to make your domain entities always valid, always consistent. How you make them consistent right from creation is simply through the entity's constructor or a Factory that will check that the provided input is good enough to construct a valid entity.
Do you create a DTO and give the domain object a Create method that
takes the DTO?
The Domain layer doesn't have a dependency to other layers, so you can't reference an external DTO there. Entity constructors and Factories typically take primitive values or value objects (sometimes other entities) as an input, not DTO's.

Restkit: Mapping parent reference to child object

Is it possible to write something similar to this code so that in the child objects I get a reference to parent object during the mapping process? Let's assume I have a child object with a property of type ParentClass called parent:
RKPropertyMapping* parentPropertyMapping =
[RKRelationshipMapping relationshipMappingFromKeyPath:#"#parent."
toKeyPath:#"parent"
withMapping:[mapping copy]];
[mapping addPropertyMapping:parentPropertyMapping];
I can later traverse from within the child objects to their parents.
UPDATE 1:
The code above is used by any entity in the hierarchy of JSON objects (except strings, numbers, etc). That is, it tries to set the linkage between the nested json objects and their owners (parents).
JSON response body:
response.body={"returnCode":{"messages":[],"name":"OK","returnCode":1}}
There is a ReturnCodeClass and a MessageClass both with a parent property. I'd like to have a reference (parent) pointing back to the owning (parent) object from these nested objects. E.g. from every message to the returnCode. In case of NSManagedObjects it is done automatically by the inverse relationship. But in case of NSObjects I try to emulate this behavior with using the #parent accessor.

How can I specify a parameter for a contructor which is used by model binding in MVC3?

Model Binding creates a new object which it maps the form fields to. It usually requires an empty contructor for this object. However what if you wished to pass a parameter to the ctor for it to say retrieve a record for the object.
I have a feeling that one needs to write a custom model builder which I am reluctant to do.
Is this possible?
Thanks.

MVC3 Custom Validation with Hierarchy Awareness

I have a hierarchical model in MVC3. All my basic validation is working, but I have a special validation that I can't figure out how to implement.
In my particular tree-hierarchy model, I have a field which must be unique/not repeat the values in any of its ancestral nodes. In my case, peers do not have to be unique.
I've tried to inherit ValidationAttribute and use validationContext.Items to store a stack of parent nodes, but it doesn't seem to me that the validationContext.Items is shared between the validation of each level. I don't know how to recursively call the validation on each child correctly, if that is appropriate.
If I'm Validating a particular node, I need access to the ancestral nodes, or some stack I create of the ancestral nodes passed to each child.
The solution shouldn't interfere with other validators or binders and should provide field-level errors rather than root-model level errors. I also want to avoid ThreadStatic, reserved strings, and other magic tricks. Yes, the entire hierarchy is bound in a single view using this technique.
Thanks!
Could you create an action filter? This give you access to the modelstate and valueProvider so you could check the data and then adjust the Errors collection as necessary.
public class ValidateForUniqueAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
// filterContext.Controller.ViewData.Model
// modelState[key].Errors.Add( .... )
}
}
[ValidateForUnique]
public class YourController : Controller

How to implement polymorphism in sproutcore?

I am developing an application that involves a type hierarchy and started by defining the models for each type via inheritance. When it comes to writing the corresponding controllers I am not sure how to approach the whole thing in a clean way. Should I write only one controller for the base type that is able to handle derived models or should there be one controller for each subtype? How should the view-controller bindings be set up to work with the different controllers?
You might want to check out SproutCore's new experimental polymorphism support: http://groups.google.com/group/sproutcore-dev/browse_thread/thread/b63483ab66333d15
Here's some information on defining sub-classes and overriding properties and methods:
http://wiki.sproutcore.com/w/page/12412971/Runtime-Objects.
From my (limited) use of Sproutcore, I've only been able to bind 1 view to 1 controller.
As such, if you are planning to use a single view (e.g. ListView) to display your data, then I think you will only be able to bind that view to 1 controller. This means the 1 base type that is able to handle derived models seems to be the way to go.
Typically you populate the content of ArrayController instances with the results of App.store.find calls. SC.Store#find can take an SC.Query instance, which typically looks like:
MyApp.myController.set('content') = MyApp.store.find(SC.Query.local(MyApp.MyModel));
This should return all instances of MyApp.MyModel, including any instances of MyApp.MyModel's subclasses.
The first argument to SC.Query.local can either be an SC.Record subclass or a string referring to the subclass. So if you've got some intermediary SC.Record subclasses, you might want to try using them there.
Controllers should just be proxies for objects, when dealing with single instances of your model. In other words, ObjectController can proxy anything. Here is what I mean in code:
You have two objects, Person and Student.
App.Person = SC.Object.extend({
// person stuff here
})
App.Student = App.Person.extend({
// student stuff here, you have have all Person things because you are extending person.
})
You then want to define controllers:
App.personController = SC.ObjectController.create({
contentBinding: 'App.path.to.person'
})
App.studentController = SC.ObjectController.create({
contentBinding: 'App.path.to.student'
})
note that you would only bind the controller's content to something if the person/student is a result of a selection, or some other flow where bindings fire. In other words, if you set the person manually (say from a statechart, as the result of an interaction), you would still define the controller but would do
App.personController.set('content', person);
You set up the controller differently depending on whether the Person is a 'top level' object in your app, or some intermediate object that gets selected. Also, you might only need one controller, you would only have a studentController and a personController if you were acting on a person and a student at the same time. Both are just ObjectControllers, and those can proxy anything.
Finally, in your view you would bind the relevant view element to the controller:
...
nameView: SC.LabelView.design({
layout: {/* props */},
valueBinding: SC.Binding.oneWay('App.personController.name')
})
...
note that the oneway binding is if the name is not going to be changed on the view, if the view can change the name, then just do a normal binding. Also note the path here. I am not binding to
'App.personController.content.name'
Since the personController proxies the object, you bind to the
'namespace.controller.property-on-object-controller-proxies'
If you are putting a lot of business logic in your controller, you are doing it wrong. Controllers should just be for proxying objects (at least ObjectControllers should be). Business logic should be on the models themselves, and decision making logic should be in statecharts.

Resources