How much factorize an AppFunc?

74 views
Skip to first unread message

Giacomo Stelluti Scala

unread,
Feb 22, 2013, 3:02:54 AM2/22/13
to net-http-a...@googlegroups.com
Hi all,
suppose I need to create an Owin application that expose a REST service. (This is not an hypothetical question, I really need to develop such thing and evaluating various ways).

How it would be factorized? Everything in a single AppFunc?

Same question for middleware. I've seen in Katana an Microsoft.Owin.Auth middleware and basic specialization Microsoft.Owin.Auth.Basic.

Is this a rule? Are there guidelines?

Thanks in advance,
Giacomo


Chris R

unread,
Feb 22, 2013, 9:13:13 PM2/22/13
to net-http-a...@googlegroups.com
Most applications use one or more frameworks to do the heavy lifting, OWIN is just the pipeline glue.  For example you can place WebApi in your pipeline to handle REST operations. (http://aspnet.codeplex.com/SourceControl/changeset/view/b7090b4bc822#Samples/Katana/WebApi/Startup.cs)

If you only need one component/framework to handle your workload, then sure, you may only have one thing in your pipeline.

"Is this a rule? Are there guidelines?" - What rule are you referring to?  The Katana components are very granular because we expect people to pick and choose the ones they need and assemble them as they see fit.  Granularity also helps with testing.  Applications are similarly unlikely to be a single AppFunc, but rather a chain of AppFuncs that implement individual pieces of the system.  Consider Microsoft.Owin.StaticFiles, which actually contains several separate middleware for directory browsing, default file names, and serving files.

Here's a pipeline example from a real app (Jabbr.net: https://github.com/davidfowl/JabbR/blob/master/JabbR/App_Start/Startup.cs)


Date: Fri, 22 Feb 2013 00:02:54 -0800
From: zero.o...@gmail.com
To: net-http-a...@googlegroups.com
Subject: How much factorize an AppFunc?
--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstrac...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Giacomo Stelluti Scala

unread,
Feb 23, 2013, 3:43:47 AM2/23/13
to net-http-a...@googlegroups.com
Chris,
as always thank for good points and links I'll investigate.

I think that testability is a primary concern and one of the first reason to moving toward this architectural standard.

Best Regards, Giacomo
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsub...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages