This is a pretty fundamental question when using NHibernate in a web application, but I don't see any agreed best practice when searching the web. I've seen it done in lots of different places:
Created and disposed in the Repository method - This just seems silly to me, since when you get the object it's already detached.
At the beginning and end of the Controller Action - This seems better, but annoying to have to do it for each action.
At the Application level, in global.asax beginrequest and endrequest - This seems the best idea, but again, I've seen some examples creating in Init instead of beginrequest (sharp architecture for instance) - although I am not sure why.
Maybe there are other approaches?
Can IoC containers help in some way here?
Maybe you know of a good resource on the web regarding this?
And - what method do you use?
Thanks
Session per Request is probably the most used approach.
I've seen some examples creating in Init instead of beginrequest (sharp architecture for instance) - although I am not sure why.
In IIS 7 You can have access to the Session state in the Init event of Global.asax. That's why sharp arch uses beginrequest.
As for session management I agree with you - Global.asax is the best place for it. Event if you want to have a clean separation between layers and remove DAL settings from UI you can use HttpModule for it.
Also you can have a look at ayende's blog. It explains his way of session management
Related
I'm learning to develop cocoa apps, yet I'm jumping straight to Core Data. Well, it seems to be the right way to write the app I want. So, I've been looking into Magical Record and found this really helpful tutorial which explains how to setup Magical Record on your AppDelegate.
Problem is I'm building a document-based app, so I have a context per NSPersistentDocument which is magically setup and available for me through the managedObjectContext property.
So, first, I don't know if I should hook up MR to this context or override the Core Data's stack creation in my document class to use MR.
So how do I setup Magical Record here?
I've been checking around the net to find some information or source code to achieve this. The thing is, that the Application I am developing uses a custom framework we are also developing. And our customer wants to add Push Notification support for the App.
But he wants the Framework we created to handle the Push Notifications (rather than the App). The following graph will explain a bit better the situation:
The problem is that the AppDelegate seems to be the only handling the Notifications from the OS, so the only solution I can think of is the App forwarding the notifications that come from the OS to the Framework. Any ideas or thoughts? Am I missing something?
Txs in advance
You will have to forward the calls. It should only require a few lines of code added to the appdelegate to interface with your framework though.
You could also do a hacky and more advanced approach where you swamp the IMP's of the AppDelegate methods and forward them through your framework. Just make sure you call the original imp once you're framework has done what it needs to. I wouldn't recommend this approach though as it may not remain stable for future ios versions.
Forwarding the calls is the way to go in my opinion.
I've been strugling with WCF to do REST the way I want it to work. And apparently so has quite a few others. I've heard about the WCF Web Api project, but wrongly dismissed it without looking too closely at it. Sadly, now that I'm looking at it I find that the documentation is rather outdated. Like, this blog post has some nice information, but classes have changed, parameters have changed, in short, design has changed.
So I've been using an old example of how to plug in Json.NET (newtonsoft) as my serializier, only to realize that after I had it working, it wouldn't work for my IErrorHandler. Further I had a problem with how to Deserialize a string from the uri template to an operation Type parameter.
It appears however that I should be able to solve these two problems (and presumably many others that I haven't stumbled over yet) by using the media formatter extension point and what's referred to as Processor<..>s in outdated documentation, which is now HttpOperationHandler<..>s unless I've missunderstood.
My problem is rather basic, I can't figure out how to correctly configure my IIS-hosted app to use my operation handler, assuming I've implemented it correctly. Since it feels rather dumb to ask for instructions on such a basic thing, I'll rather ask where I can find some documentation on how to do this sort of thing? (Explanations are welcome of course.)
I'm not after seing which classes exist, or what their methods are named with what parameters. I can see all that in my object browser. I need documentation for the overall design, and/or examples implicitly describing things like:
How do the different classes in the API fit together?
How can I configure from web.config?
Must I rather do a custom HttpServiceHostFactory?
What and how are you meant to use the framework?
How should I extend to reach what sort of goals?
How should I configure to place the extensions in effect?
From the lack of answers I assume the documentation quite simply isn't ready.
I was looking for it on the codeplex site under the Documentation tab, and found outdated stuff.
However, after familiarizing myself a bit with Codeplex I found out that the good stuff was in this Discussion section. Searching a bit in there helped a lot to be honest.
Concerning config-file configuration, I didn't find anything, so I'm assuming this will be added as the last thing before official release. Meaning I'll use the HttpConfiguration in a custom HttpServiceHostFactory for now.
The trick about the HttpOperationHandlers was twofold: Firstly I was throwing an exception in my operation and hadn't implemented a global HttpErrorHandler yet. (Doh!) Secondly I didn't know that the parameter name of HttpOperationHandler<..>.OnHandle had to match the name of the operation parameter.
Has anyone found a smart way to use NServiceBus, without having to implements that useless IMessage marker interface for all messages?
Especially, when using DomainEvents, I would absolutely hate to couple my domains to a specific servce bus implementation.
I just noticed that Udi is adding an Unobtrusive Mode to NServiceBus 3.0. It appears
that will address the issue. There's even a sample writeup, but you would have to pull the latest off github at this point (Feb 2012). If you're willing to put up with some potential instability to get pure POCO messages, you might give it a try.
The IMessage interface is needed so that NServiceBus can automatically register those types in the serializer. When using domain events, it isn't recommended to publish them directly on the bus - instead, a domain event handler would translate them to service-level events (which inherit IMessage).
You might be able to create your own interfaces implementing the NSB marker interface and then ILMerge the NSB dependencies into your own DLL. This should allow you to only require references to your own Dll and no external references to NSB.
Its what NSB does for its own dependencies so you should be able to extend the idea, be sure to check out the pitfalls of this approach though - Udi blogged about it recently
http://www.udidahan.com/2010/08/01/cautiously-merging-il/
Six months later, still nothing about this issue (fix/improve) ??
Summary of possible solutions:
1) ILMerge or..
2) Custom Dispatcher for custom wrapped messages.
All this because of the IMessage marker interface.
Just say you have a quite large and complicated desktop application written in objective-c/cocoa written properly in MVC. You then wish to replace the V and C so that it is a web application?
Is there anything like Tomcat but for objective c? The closest thing I can think of is somehow convert the Model code into an apache module to load in apache?
Obviously I could embed some sort of HTTP server and write a whole pile of code to manage sessions and requests and responses and so on, but might there be a simpler way?
You can leave the server almost as-is. I'd run it as a daemon in the background.
I'd split the controller part. One part of it resides on the server as a connection between HTTP requests and the daemon.
You could run a self-made http server.
You could build it into a Apache module as you mentioned.
You could access your controller through CGI. This is the easiest option as I see it.
The second part of the controller is written in Javascript in the browser, exchanging data with the server and updating the GUI.
The view part is written completely in javascript.
You could - if you want - leave out the controller on the server and make the model understand HTTP requests.
For the Controller / View part consider using a framework.
jQuery for only a light interface. (Or a similar framework.)
I haven't yet found a framework that leaves all the model stuff to the server. Maybe you can use SproutCore or Cappuccino accordingly.
SproutCore, the full-backed MVC framework that is used by Apple. (Think so at least.)
Cappuccino, another full-backed MVC framework.
Have you looked at Cappuccino? http://cappuccino.org/
I have not used but have heard many good things about it.
There is a new web development platform for Objective-C/Cocoa called Bombax. It sounds like exactly what you're looking for (it is designed to allow you to write entire web applications in Objective-C). Perhaps you could even combine it with Cappuccino. You can check it out at http://www.bombaxtic.com.
The closest you'll probably come to Objective-C web frameworks are either SOPE, or GNUStep, neither of which I have used, but ran across when I was deciding if I wanted to use Rails or something written in Objective-C for my web stuff. There's also ARJDatabase, which is kind of like Core Data, but not source compatible.
The bottom line is, unless you were very careful about how you wrote your code (i.e. wrote it with GNUStep in mind, didn't use anything Apple specific) you're probably going to have to do quite a bit of work anyway. And if you used Core Data at all, there's no way I know of to reuse that outside of a Mac App. And since it's not setup to be used my multiple simultaneous users, you wouldn't want to use that in a web app anyway. Bottom line, I went with Rails.
There is Frothkit - http://code.google.com/p/frothkit/ but it appears not to have been updated for a year.