Do you know any blueprints for organizing a WCF application in a way similar to Service Factory?
The problem is that although Service Factory is well organized, my application is a medium-sized one and it would be an overkill to use the factory - some of the sub-projects that the factory creates for me, I wouldn't ever use.
So what are the common models/architectures/blueprints/patterns for organizing the structure of a WCF application for a mid-sized project?
Thank you.
This article is great in terms of how to set up your project structure the right way:
http://code-magazine.com/Article.aspx?quickid=0809101
Related
I'm architecting a new App and I really unconfortable with this approach in ASP.NET Core that made "normal" adding a DbContext by using AddDbContext, in services.
I'd like to know if you guys think that using AddDbContext in ASP.NET Core isn't a bad practice, since it forces my Web App to have a dependecy on my database access layer.
I've researched a lot and it was incredible that there isn't almost anything that cover this subject.
How should I proceed to overcome this concern?
Thanks!
it forces my Web App to have a dependency on my database access layer
That's exactly the place where it should be: the composition root. Your application startup code is the place where you glue your components together.
What else would you want, create a separate library, containing interfaces for all classes in your entire DAL, and wire that up using magic during startup?
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
I am going to use Entity Framework and WCF in my application. The suggested practice, as I saw, is using POCO with Entity Framework and also using POCO classes as DataContracts. That is actually what POCO and Attributes are used for, -if I am not wrong.
However I am asked to use seperate classses for Entity Framework POCO's and WCF DataContracts. And to use a mapper between POCO's and DataContracts. Like, Foo and FooContract with same properties.
I am on the first approachs side but I wonder if the second approach (seperate classes approach) provides flexibility to the application or is it just a waste of effort.
I will be grateful if you can share your thoughts and experiences about using seperate classes for POCO and DataContracts, pros and cons about that.
Having separate classes for your POCOs and your Contracts will allow you to create Message Oriented services rather than RPC Style services.
Having Message Oriented services will allow your services to be more flexible, do more work, and be less tied to the objects that each service uses.
Message Based services also fall more in line with the spirit of Service Oriented Architectures. You can read more about Message Oriented services at Wikipedia.
I would also suggest picking up Service-Oriented Architecture: Concepts, Technology & Design by Thomas Erl if you are interested in the principles behind good service design.
Having different data classes at persistence layer and contract level gives you the most flexibility. For example, you may not want to expose all your persistent fields over a contract or you may want to expose different hierarchy of data over a contract etc. It also allows to change both independently of each other.
It may seem at first that using different classes at both level is duplication - but over long term, efforts are not so much (compared to flexibility that you get). You may get tempted to use same classes and develop different one when need arises but issue with that approach is that within short time frame, your services get tightly coupled with data classes rather than information/data that services should be exposing/working with.
I agree with #JustinNiessner and the best guidance I have found for architecting .NET applications using SOLID principles is a series of posts by .Net Junkie and the associated codeplex project. Clearly stated and informative, well worth reading.
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 am building a WCF application, using NHibernate for the persistence layer. A lot of documentation thats out there is about using NHibernate with ASP.NET applications. But very little on the best ways to manage NHibernate Sessions in a WCF application.
After reading up on Instance Management Techniques in WCF applications, I am going to use "per-call Services". Drawing parallel with ASP.NET, this is like opening NHibernate sessions on Application_BeginRequest and closing them on Application_EndRequest. Billy McCafferty's S#arp Architecture has a great example of doing this very elegantly. But I am finding it a little hard to use a similar concept in a WCF application.
Any code samples or pointers to blogs with examples, will be greatly appreciated.
http://www.igloocoder.com/archive/2009/04/23/wcf-and-nhibernate-redux.aspx -> https://igloocoder.net:8443/svn/IglooCommons/trunk/src/IglooCoder.Commons/WcfNhibernate/
I found another good example -
http://realfiction.net/go/133