I have been looking for a good example of WCF and NHibernate facilities working together, (one session per web request, etc) but all the tutorials i find are dated 2009 and older. I am afraid i may lose my time trying to implement all this when there are probably better ways to achieve this.
The other thing i noticed is that Rhino.Commons.NHRepository was popular three years ago, but i can't find anything related to this assembly more recent than that. Any reason for this?
Anyone can point me on good examples on how to implement WCF and NHibernate using facilities?
NHRepository? RIP?
Thanks
It seems to be dead. I would suggest you to use one of popular IoC containers to manage lifetime of session and session factory. Almost all modern containers have integration with WCF including per request lifetime.
Related
Is it even possible more or less natively consume WCF service from Go application?
I can imagine it should be possible to execute SOAP calls in Go, but WCF is a bit more than that only, for example authorization will probably be a problem also...
Have anyone at least approached this area, or maybe someone can give useful me advice in this "wheel reinvention task"?
Thank you in advance for all your input, ideas and suggestions.
I think you should expose a RESTful Service. I myself have the problem with exposing a WCF Service too many clients using PHP, Go, Ruby and all kind of languages. We never ever got it right, to automatically generate a proxy.
The maybe simplest way is to use WCF, like described in this example:
https://www.codeproject.com/Articles/105273/Create-RESTful-WCF-Service-API-Step-
By-Step-Guide
But I recommend to switch to ASP.NET Core (Migration is not that hard) or if you have the budget I would consider https://servicestack.net/
It may be well beyond the wait time for this. However, here is something really interesting that could help. The situation the authors found themselves is relevant even today in some organizations.
https://github.com/khoad/msbingo
Here's the motivation provided by the authors:
Application/soap+msbin1 encoding was a blocking issue for modernizing services from WCF to platform-agnostic technologies such as Go. We needed to be able to make calls to dependency services that spoke msbin1 and were not going to be updated or even reconfigured, but we did not want to introduce unnecessary complexity such as workarounds like .NET-based WCF request translator proxies or deploying Mono with our service instances. Initially we tried the Mono deployment route, which, while it would have worked well enough, significantly complicated our deployment pipeline, thus erasing one of the major advantages of golang.
I found it a useful starting point to begin experimentation.
There seems to be quite a bit of information regarding using NHibernate and WCF Web Services but I'm struggling to find a definitive guide on how to implement the two technologies together in a efficient, thread safe way.
Specifically I want to grab the ISession object and uses that to get and save data through my existing repositories. My Business Objects, Unit Tests and ASP.NET Web Application all use the NHibernate framework and it works just great (it's my first hobby project using an ORM). My big question is how to combine this great framework with WCF Web Services.
I've read that version 3.0 NHibernate has NHibernate.Context.WcfOperationSessionContext but I'm unsure of it's implementation (see this question). From what I understand, one option is to store the ISession object in the OperationContext?
Can anyone point me in the direction of a implementation example?
Many thanks.
Here is a post describing, in detail, all the steps for registering and using the WcfOperationSessionContext. It also includes instructions for using it with the agatha-rrsl project.
WCF and Nhibernate work together in Sharp Architecture project. You can have a look at their implementation
A silly question, perhaps, but at this time of night, StackOverFlow is my only friend.
I'm playing with NHibernate and wanted to factualize these 2 statements regarding Sessions in web applications.
1) You should only ever have 1 ISessionFactory per database for the lifecycle of an application.
2) You should only have 1 ISession per HttpRequest or batch of HttpRequests (i.e. conversation)
[I don't want tool or framework recommendation, just want to confirm the above]
You should only have one ISessionFactory for the lifecycle of the application.
Session-per-request is how I work with NHibernate. There may be other patterns, but this is the one that I stick to in my web projects.
You are correct in your assumptions.
Session-per-request is the most common pattern for web applications, and plays nice with MVC, web farms, etc.
There are some ready-to-use modules to handle these patterns at http://unhaddins.googlecode.com/svn/trunk/uNhAddIns/uNhAddIns.Web/ (you can check the rest of uNhAddIns too)
We currently utilize Session-per-Request however I have come across issues with this approach in some cases.
I don't think the answer is that generic, and you should consider using one session per unit of work as well.
Especially when it comes to automagic flushing of entities the Session per request might bite you in the ass.
I'm looking at new architecture for my site and was wondering if pairing NHibernate with a web service core is a good idea. What I want to do is make my webservice the core of my business, from the site front ends to the utilties I write. I'm trying to make all of my UIs completely ignorant of anything but my service API's.
In a simple strawman experiement, I'm running into issues with Serialzing my Iesi ISets....this is causing me to rethink the strategy altogether.
I know I could just develop a core Library (dll) and reference that in each of my applications, but maintaining that dll's version over a minimum of 6 applications seems like it's going to cause me much pain.
With NHibernate, what are the pro's and con's of those two approaches?
I see no problem in using NHibernate and webservices together - I just don't think it's a good idea to send the entities themselves over "to the other side".
A better approach is to use a set of DTOs that are made for the service - then you won't be running into issues like that of serializing unknown types and such.
You can use a library like AutoMapper to do the mapping from the entities to the DTOs.
There's a lot of stuff written about this, some of it:
http://martinfowler.com/bliki/FirstLaw.html
http://ayende.com/Blog/archive/2009/05/14/the-stripper-pattern.aspx
http://elegantcode.com/2008/04/27/dtos-or-serialized-domain-entities/
DTOs vs Serializing Persisted Entities
As a side note for the service it self, you could design wise use an approach like Davy Brion describes here: http://davybrion.com/blog/2009/11/requestresponse-service-layer-series/
I don't know NHibernate, but want to remind you that you should be using WCF for new web service development, unless you are stuck in the past (.NET 2.0). Microsoft now considers ASMX web services to be "legacy technology", and you can imagine what that means.
I work for a large state government agency that is a tad behind the times. Our skill sets are outdated and budgetary freezes prevent any training or hiring of new employees/consultants (firing people is also impossible). Designing business objects, implementing design patterns, establishing code libraries and services, unit testing, source control, etc. are all things that you will not find being done here. We are as much of a 0 on the Joel Test as you can possibly get. The good news is that we can only go up from here!
We develop desktop CRUD applications (in C++, C#, or Java) that hit the Oracle database directly through an ODBC connection. We basically have GUI's littered with SQL statements and patchwork code. We have been told to move towards a service-oriented n-tier architecture to prevent direct access to the database and remove the Oracle Client need on user machines.
Is WCF the path we should be headed down? We've done a few of the n-tier application walkthroughs (like this one) and they seem easy to implement, but we just don't know enough to understand if we are even considering the right technologies. Utilizing the .NET generated typed DataSets seems like a nice stopgap to save us month/years of work (as opposed to creating new business objects from the ground up for numerous projects). Is this canned approach viable for a first step?
I recently started using WCF services for my Data Layer in some web applications and I must say, it's frustrating at the beginning (the first week or so), but it is totally worth it once the code is deployed.
You should first try it out with a small existing app, or maybe a proof of concept to make sure it will fit your needs.
From the description of the environment you are in, I'm sure you'll realize the benefit almost immediately.
The last company I worked for chose WCF for almost the exact reason you describe above. There is lots of good documentation and books for WCF, its relatively easy to get working, and WCF supports a lot of configuration options.
There can be some headaches when you start trying to bend WCF to work in a way not specifically designed out of the box. These are generally configuration issues. But sites like this or IDesign can help you through those.
First of all, I would definitely not (sorry for the emphasis) worry about the time you'll save using typed DataSet's versus creating your own business objects. That is usually not where you will spend most of your development time. I prefer using business objects myself.
In you're situation I would want to implement a proof-of-concept first. One that addresses all issues you may encounter. This proof-of-concept should implement an entire use case, starting on the client, retrieving data from the database and returning it to the client. You should feel confident about your implementation before continuing.
Then about choice of technology. WCF is definitely a good choice for communication between your client applications and the service layer. I suppose that both your clients as well as your service layer will become C# applications? That makes things a lot easier since interoperability between different platforms (Java/C# for example) is still not trivial although it should work in most cases.
Take a look at Entity Framework (as there are a couple Oracle providers available for it already) in conjunction with .NET 3.5 SP1 which enables built-in WCF serialization of your EF generated classes.
Here is a good blog to get started: http://blogs.msdn.com/dsimmons
CSLA might be a good fit for your N-Tier desktop apps. It supports WCF, has a large dev community, and is well documented. It is very object oriented.