-
Notifications
You must be signed in to change notification settings - Fork 0
FAQs
Strictly and semantically speaking, no. However, in reality developing with OpenRasta strongly resembles MVC development. Every part of the MVC triad has a direct counterpart in OpenRasta. The “Model” can be seen as “Resources”, the “View” can be seen as a “Codec”, and the “Controller” is a “Handler”. If you were looking for the main difference in a nutshell, it’s that OpenRasta’s Codec mechanism is like the View part of MVC but vastly more flexible – you get to support many different representations of the same resource, whether you’re writing that representation to a client’s browser or responding to a client POST or PUT.
Yes.
OpenRasta supports Castle Windsor and NInject out of the box, although you don’t actually ’’’require’’’ them. OpenRasta has its own built in dependency resolver if you don’t need the heavyweight IoC support that these external frameworks provide.
You just add .AsXmlDataContract()
and .And.AsJsonDataContract()
to the fluent configuration for a particular resource/handler combination. See the Configuration How Tos for a full example.
First you’ll need to implement the codec. When you’re done, you’ll need to register it using the fluent configuration. See the Configuration How Tos for an example of registering your own codec.
If your handler method currently returns a resource class (for example, a Customer
), change it to return an OperationResult. This operation result can optionally return the resource as part of itself, for example
public OperationResult GetCustomer(int customerId)
{
return new OperationResult.OK { ResponseResource = CustomerRepository.GetCustomer(customerId); }
}
h3. … serve a custom error representation when something went wrong?
See Serving resources using .WithoutUri() in the Configuration How Tos.
- For Ninject, see Dependency Injection with Ninject.
- For Castle, see Dependency Injection with Castle.
.WithoutUri()
allows for circumstances where you need to serve a resource of a type other than the one that was requested. The common use case for this is serving a representation of an error which occurred when asking for the resource you really wanted. See Serving resources using .WithoutUri() in the Configuration How Tos.
[[PipelineContributors]]
are of use when you need to modify at a fundamental level what the pipeline is doing; what it’s going to render, whether it should even continue at all – they should be seen as the lowest-level type of extension with potential to severely affect your site if you get it wrong.
UriDecorators are used when one needs only to add context to a call based on something the URI contains.
IOperationInterceptor
implementations should be used when you need to do something on a per-call basis but don’t really care where in the pipeline they execute – just that they occur before or after the handler method takes place.
(with thanks to Barry Dahlberg)
You might want to use your favourite IoC container for a couple of reasons:
- You have existing infrastructure you want to leverage.
- You want to use advanced features of a container (for example, proxy generation).
Yes, it does, but is not part of the installation in the release candidate edition. It will be part of the default RTM build.