I have some experience with NHibernate and I'm trying to get started with Castle Nhibernate Facilities OR Castle NhibernateIntegration. I'd like to know, where I can find a demonstration project of how to configure and perform transactional control (with attributes) in a service layer (business, class library project)? There is no documentation, and I have a really difficult to find some content to getting started.
I found some samples on the web but only with pieces of code and not the demonstration project... I would like to download something to study. I'm not finding to a complete solution, just the configuration and transactional control in business classes (class library).
Sorry for this kind of thread here, but I do know how to start.
Thank you!
If you want to see an full example of Castle Windsor integrating with nHibernate then I would check out Sharp Architecture
Sharp is an attempt at a 'best practice' template project and utilises a number of tech's (Castle and nHibernate included). While some of the things it does may not be to your taste it will clearly show you one of the ways that it can all fit together.
You may need to go hunting into the source repository on GitHub if you want to see what is going on at a low level as Sharp uses it's own base classes in the template project that are pre-compiled (tho its still open source so you can see what is going on if you want).
It was an invaluable help to me when I was putting my architecture together and I can honestly say that Castle and nHibernate are the way to go, so you are very much on the right track.
EDIT FOR COMMENT 1: Perhaps I am a little confused here. According to the Castle notes
Facilities are main way of extending the container. Using facilities
you can integrate container with external framework, like WCF or
NHibernate, add new capabilities to the container like event wiring,
transaction support... or to components (synchronization, startable
semantics...).
To the best of my knowledge both Castle Nhibernate Facilities and Castle NhibernateIntegration are Facilities and must be based on a container.
If you want to work without a container then you need to use some form of Singleton Factory to manage the SessionFactory. There is an example of this here.
In terms of attributes controlling Transactions then this is how Sharp does it (see here). You may get away with reusing this code and replacing NHibernateSession with your own Singleton like theirs.
You don't need to implement UnitOfWork as nHibernate is effectively doing this for you. What you really need is an architecture that allows you to manage a transaction at a single point of control (Singleton) and is available in every repository.
Related
I recently posted a question regarding NHibernate. This lead me to check Codesmith's framework PLINQO for NHibernate.
At the same time, i was reading a tutorial on nhibernate at their official site (as i was looking at the generated project by PLINQO).
I am not an expert on NHibernate but what i am looking at right now (PLINQO Generated NHibernate project) looks to me very sloppy, pretty much a recipe for disaster. It creates a set of "Entities" that i am guessing is the business object? A big mess to my eyes.
Does anyone has experience with Codesmith's NHibernate?
Can anyone point me to a mc daddy of NHibernate. I have found so many variants so far that i am already overwhelmed with all this.
Thanks you.
I work for CodeSmith Tools. How do you feel the generated project looks sloppy? How would you improve it? We try to separate out the entities (POCOs) / hbm's for consistency and easy of use (as Randy detailed above). The Entities are generated directly from what is defined in the hbm file, which can be customized without losing your changes.
The generated project follows the architecture of Linq-to-SQL and Entity Framework. We feel this allows developers on the Microsoft Stack to switch between backends quickly (NHibernate to EF or EF to NHibernatE) while minimizing the amount of code changes.
The generated datacontext manages the NHibernate sessions for you while giving you access to query extensions, caching and much more. Also, you don't lose any core NHibernate features as we just extend the core libraries. All of the core features are available on the DataContext under an advanced property.
P.S., The best place to post questions and get a timely response is via our forums.
I'm starting to find myself getting more and more in to using WCF for projects I implement for internal use (automating company tasks, making sure all clients are on the same page, etc.) This is largely due to the 3-10 clients I am automating at once whenever I do implement a solution, and (even if it was a small sample) the company is growing which continually adds more clients in the pool and thus a higher demand for reliability/consistency. With that said, I'm recognizing how important it is to make sure I make things expandable as (previously) pushing a release was getting harder the more clients I have depending on the service.
My latest project has a potential of being externalized. Until now I've done it the way I know works, but I'd still like to travel down the "right" path in terms of future updates. How should I be setting up my project file to make this as easy and seamless as possible to keep maintained, up-to-date and expansive? Should I be placing version numbers in to the namespace (as in Company.Interfaces.Contracts.June2011.IMyService), using pseudo folders, ...?
I just don't feel confident in this aspect of moving forward. I'd like to know that whatever ground work I have in place now won't place burdens on future expansion/customizing later. I'd also like to stick to the "development norm" as much as possible as it's getting more plausible that we'll hire additional programmers to help the work load.
Does anyone with this kind of experience have any thoughts, suggestions, guidance in this field? I would really appreciate any examples, books, documentation, etc. that you can provide.
Update (06-17-2011)
To give some insight, I'm also looking for some specific questions. These include:
How do you decorate a service class vs a DTO in terms of namespace? I've seen http://service.domain.com/ServerName/Version used on the Service class itself & http://types.domain.com/ServiceName/Version used on the DTOs. Is this common? (Separate the namespace in to a type and service collection?)
Should I be implementing IExtensibleDataObject on all my objects on the basis that they could potentially be evolved in future released? (Lay the ground work out now)
If my database has constraints on it for (e.g.) string length, I should be extending IParameterInspector and using that method for validity (keeping logic and validation separate), correct?
Should the "actual service" be broken out in to its own class so, as I version, the Service Contract classes just call the code (keeping each new version release with an minimal code as possible?) Or should I keep it within the service class and inherit from it with any new methods (likewise, what happens should you remove a method?)
I'm sorry if I have a lot of questions, I just see two ends of the spectrum in documentation. I see "Setting up wcf" then directly to "this is a versioned WCF"--no segue/steps between. I'm assuming it's going to just "click" once I get enough information, but I'm (sadly) not there yet.
tl;dr
When you start writing a WCF service that you know is going to hit several iterations, how do you setup your project(s) to make it as easy as possible in the future (on yourself and teammates)?
I have had success using a "strict" versioning policy (it seems from past experience you are heading in this direction anyway) where you simply create new endpoint/s each time a new definition is released. This means you won't have any contract backwards compatibility concerns for legacy clients - older versions can easily be turned off once logging indicates all clients have upgraded. It is generally necessary however to write bridging code for any legacy endpoint/s so they can continue to call into the modified business logic.
In terms of project organisation, I would create a new project for each version so they can easily be deployed separately. Namespaces using v1, v2 are normally works well enough. The endpoint names can also include a version number which should easily distinguish them from each other.
Alternately you could try using a "lax" versioning policy where you can have the ability to add or remove data members by implementing the IExtensibleDataObject interface in all your services. Some useful MSDN article links can be found in a popular response to a similar question: WCF client's and versioning.
Another "lax" kind of option is to move more towards a messaging solution (which WCF can support through message contracts and/or the MSMQ binding). Here podcast by SOA guru Udi Dahan that provides an interesting perspective and is definitely worth a listen - there is no IDog2.
Finally here is a good blog post with some further more fine-grained guidelines on whichever strategy you end up using:
http://wcfpro.wordpress.com/2010/12/21/wcf-versioning-guidelines-2/.
I've become pretty enamored of the Seaside web framework lately. I'd like to start digging into the source to figure out how it works. Unfortunately, there are a lot of classes and I don't know where to start! Does anyone know what classes I should try to understand first? I assume that there's a routing class somewhere that I should start with...
Stephan gives good suggestions. Basically, if you understand the Seaside-Core package in Seaside 3.x, you understand how everything fits together:
The Canvas stuff is all a specific implementation of WARenderer from the Seaside-Core-Rendering category
The Session/Application stuff is all a specific implementation of WARequestHandler from the Seaside-Core-RequestHandling category
The Component/Task stuff is all an implementation of WAPainter from the Seaside-Core-Presenters category
There are really two ways of approaching studying the framework. Either start with one of the specific things you are interested in (say WAComponent) and work your way up the superclasses. Then repeat with each of the other classes Stephan mentions.
I'd suggest the other way: starting with the three sets of abstract classes I mentioned in Session-Core. Looking at them together (combined with the HTTP and Document classes) will give you an idea of the generic concepts and how they plug together to form the framework. You can look at each of the specific implementations as needed to relate the generic concepts to the actual implementation.
Subclasses of WAServerAdaptor form the starting point of request handling in Seaside, where a request from a specific web framework is converted into a Seaside request and dispatched to an appropriate handler. Callbacks are also pretty important and are in Seaside-Core-Callbacks.
If you understand everything in Seaside-Core, you basically understand how the framework works at a high level. Once you have a broad understanding of the basic core concepts, you can then proceed to get a deep understanding of each area that interests you by examining the concrete implementations in more detail. But keep in mind that everything in Seaside-Core is intended to be subclasses and plugged together to extend the framework.
I assume you have read the Seaside-Book?:
http://book.seaside.st/book
If you want to go deeper just look at the source, starting with the classes WAComponent and WARenderCanvas+WAHtmlCanvas. The routing class is WAAdmin in the sense as "this is the place where different Seaside-apps are registered".
There are several parts that are interesting. Start from WARenderCanvas to understand how the html generating dsl is build. WAComponent is the starting point for the composite page structure with call: and answer:. WAApplication represents a Seaside application, WASession a session, WAServerAdapter connects the Seaside framework to a http server and WARequestHandler handles http requests. The Grease package handles differences between Smalltalk dialects.
You are using the different browsers (class and hierarchy), class commments and senders and implementors, aren't you?
I'm looking for a decent codebase that demonstrates how to use nHibernate as the persistance layer in an asp.net mvc3 project.
The two key pieces of understanding that I am looking to develop are
How to deal with ISession and
ISessionFactory.
How to implement the repository pattern without leaking any details of its nHibernate implemenation.
I'm aware of Sharp Architecture and reading through that now - Its interesting but I'm more keen on finding a straight-forward web app to pick apart than another framework to learn.
Thanks in advance.
I put together a project that offers an example of how to do this using nhibernate and asp.net mvc 2. The repository and nhibernate implementations will be almost the same. Probably the biggest change will be the ioc / dependency injection piece. Take a look. It should provide a solid starting point. Here is the URL.
http://gpsnerd.codeplex.com
Let me know if you have questions.
Bob
Take a look at https://bitbucket.org/FunnelWeb/dev
FunnelWeb is a blog engine based on ASP.NET MVC and NHibernate.
It is opensource and used by many bloggers/develoeprs
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