Hi Fabio
I believe there has been several conversations about this in the old forum. Go to http://www.searchcsla.com/Search.aspx and try searching for NHibernate using the Search Messages button. You should get back a load of threads to look through.
HTH
John.
Check out this link on the old search site: http://www.searchcsla.com/Details.aspx?msn_id=25534
We are currently using NHibernate with CSLA for our first project, which involves the addition of a Web Services interface to our existing application.
Protected Sub FetchObject(ByVal session As NHibernate.ISession, ByVal value As T)
Dim MyType As Type = Me.GetType()
For Each field As FieldInfo In MyType.GetFields(BindingFlags.Instance Or BindingFlags.NonPublic)
field.SetValue(Me, field.GetValue(value))
Next
End Sub
FetchObject(FetchObject(session, CType(session.Load(Me.GetType, _orderID), Order))
JT,
I don't quite see what you're trying to achieve with your code. NHibernate automatically puts the values from the DB into the fields for you. Unless I misunderstand your code.
Check out this code fragment I added on another thread.
It shows a very simple usage of NHibernate loading the current instance, using session.Load(this, identifier).
You don't need to manually map the data into the fields. That is what NHibernate will do for you, if you give it an appropriate mapping.
CSLA and NHibernate, or any ORM for that matter, both have completely different objectives.
CSLA make heavy use of the "domain" driven objects that encapsulate business rules and makes no attempt whatsoever to have an object that matches a database table. The 2 are completely different.
An ORM such as NHibernate tend to focus on the database schema and creates a one-to-one relationship model in that 1 table will end up as one business objects.
The advantage of using an ORM with CSLA, or any business object oriented framework, is that you can code you business object as per the business expect them to appear while not really caring how the data gets persisted in the database. The other benefit is that you can quickly, or should I say more easily, adapt you business object to persist to an other data source such as Oracle or Firebird just to name a few.
The other advantage is that _most_ ORM will generate a “typed” object for each database objects such a table or a view.
Hope this helps
I agree with Guy's comments - the two technologies are complimentary.
CSLA gives us well constructed Business Objects with rules and validation and the ability to surface them to a variety of different UIs (i.e. WebForms, WinForms, Web Services).
NHibernate gives us the ability to mark-up (with attributes) our BOs and persist them in any supported database engine (e.g. MS SQL Server, Oracle, MySQL).
They are doing two slightly different jobs and each meets a different requirement for my project.
In our case, we don't need to override the DataPortal_Fetch() in our BOs and provide all the mapping from the SafeDataReader to private member fields.
All of this is done automatically by NHibernate in our two base classes which inherit from Csla.BusinessBase and Csla.ReadOnlyBase respectively.
Hi David,
I'm interested in what you're doing with NHibernate. You're basically bypassing the CSLA DataPortal framework and utilizing NHibernate for your ORM operations instead? Yes? Any issues that you've come up against?
I'm using CSLA 2.0.2 right now, but I'm thinking about swapping out the ORM code and plugging in NHibernate. I've never used NHibernate but I understand what it does and how it works. Are the productivity gains that significant to justify such a decision?
Also, I have one more issue I would like to hear you weigh in on.... With .NET 3.0 and Linq, will NHibernate become irrelevant?
Thanks,
Paul
Paul,
We're not bypassing the DataPortal framework - we still want mobile objects. What we've done is replaced the ORM operations inside the DataPortal_xyz with NHibernate functionality, instead of ADO functionality. So we use NHibernate Sessions instead of SQL connections.
One of our goals behind the choice for using NHibernate was to achieve database indepenence, so we are not tied to a specific vendor. This may, or may not, be a consideration for you.
In terms of productivity, we have seem some benefits as we use the NHibernate.Mapping.Attributes extension DLL to simply attribute the private member fields we want to persist. That works really well and is easy to fit into a code generation template (if needed).
As for .NET 3.0 and Linq? Well I'm not sufficently familiar with either technology to comment on them just yet.
I'm thinking of converting ProjectTracker to use NHibernate to demonstrate its use. Is that something you (or anybody else) would be interested in?
DavidDilworth:
I'm thinking of converting ProjectTracker to use NHibernate to demonstrate its use. Is that something you (or anybody else) would be interested in?
![Wink [;)]](/emoticons/emotion-5.gif)
DavidDilworth:
I'm thinking of converting ProjectTracker to use NHibernate to demonstrate its use. Is that something you (or anybody else) would be interested in?
It's not available yet, we haven't done the conversion. I'll post as soon as it's available.
We haven't tried NHibernate with MySQL yet, although we are aware that there is support for it.
My company are planning to use NHibernate with CSLA but we want our business (domain) objects to be persistence ignorant and don't need the data portal approach. I was thus thinking of ripping out this functionality. Does this sound like a sensible approach?
I'm not quite sure what you mean by "persistent ignorant", perhaps you could clarify that.
As for ripping out CSLA functionality, would it not be better to leave it in and just not use it. If you don't need to use the Data Portal, then just don't use it. Set your configuration to use a connection directly to the database. The BOs will only be "mobile" if you sert up the config to work that way.
I say this from a maintenance point of view. It will be much easier to take future CSLA updates "off the shelf" if you haven't changed the code.
All I mean is that our domain objects won't, directly or indirectly, access anything that handles persistence. So you won't be able to call customer.Save(), instead it will be the process layer that will put NHibernate and the domain classes together.
How easy it is to do that will, I guess, depend on how many of the CSLA base classes are implementing methods related to the data portal.
Your probably right, I will just configure it not to use the Data Portal so thanks for the advice.
It's been few months since my last posts and detailed browsing on this forum. Shame on me ![Embarrassed [:$]](/emoticons/emotion-10.gif)
. But still I've been using CSLA in the meantime, and I-m quite happy with it. But now I'm in a need of DB independent ORM with CSLA, and thought (again) of NHibernate. Is there any sample? What about translation of PtojectTracker on NHibernate?
As I said, shame on me. Just after posting previous message I saw the answer on the other thread. Anyway, I think that David still posted some key concepts. Thanks David. So, we'll have to do something on our own now I guess ![Smile [:)]](/emoticons/emotion-1.gif)
. Sorry again for posting before reading.
The performance hit is due to the fact that if you mark up your classes with NHibernate Mapping Attributes, you need to reflect them out of the assembly to create a mapping file. There is a standard way to do this shown in the example code using in-memory serialization.
Once you have reflected out the correct mapping file, you are at the same point as if you had created the mapping file by hand in the first place. The mapping file is then used to create an NHhibernate session factory.
So (in my opinion) performance has been sacrificed for the sake of maintainability, as the code is self-documenting and the "mappings" are contained in the same source file as the class itself. If you change the class source file, you change the mappings at the same time.
That is the point the author is trying to make in the sentence you quoted.
HTH.
I have some good news for anyone interested in NHibernate.
We have completed an NHhibernate version of the ProjectTracker example project.
I am currently corresponding with Rocky to see if I can get it released as part of the CSLAContrib project on CodePlex.
Watch this space!
Your curiousity is well directed.
Actually, the implementation we used for the factory method Delete...() is to load the object first. We then mark it as deleted and go off and start physically deleting stuff.
The rationale behind this decision was down to the fact that we have modelled the parent->child collection entity relationships as an NHibernate mapping. Therefore, NHibernate "knows" what to do when you do a Fetch() within the scope of a single NHibernate ISession to get the full object graph.
When it comes to the factory Delete...(), NHibernate can't know what the "full object graph" is, unless it's already loaded. Once it's loaded then it is very easy to delete the object graph.
This implementation also supports the deferred Delete concept as well. The only difference being that the instance object is already loaded in memory.
There are examples of both these scenarios in the NUnit tests we've written, which will be included on the CSLAContrib project.
How do you suggest implementing a parent -> child collection relationship? According to what I have read and experimented with, NHibernate allows one to map a collection of object by mapping to the interface equivilent (i.e. IList). But in reality we want to map these collections to the CSLA implemented collection derived from Csla.BusinessListBase<T,C>.
I have found a way around this restriction by mapping the bag to a private property of IList and using the get and set to populate the collection derived from Csla.BusinessListBase. It looks something like this:
Pets _pets;[
Bag(3, Cascade = CascadeStyle.All)]How do you suggest implementing a parent -> child collection relationship? According to what I have read and experimented with, NHibernate allows one to map a collection of object by mapping to the interface equivilent (i.e. IList). But in reality we want to map these collections to the CSLA implemented collection derived from Csla.BusinessListBase<T,C>.
I have found a way around this restriction by mapping the bag to a private property of IList and using the get and set to populate the collection derived from Csla.BusinessListBase. It looks something like this:
Pets _pets;[
Bag(3, Cascade = CascadeStyle.All)]One thing I just found about this approach is that NHibernate does not mark the children as a child (normally by calling "MarkAsChild()") nor does it mark the children as old (normally by calling "MarkOld()"). So when copying the items from the NHibernate collection to the Csla collection, you have to somehow set those objects to as a child and as old.
Since those methods, in the base class, are protected, I just added a public method to the child class that allows the parent to pass in the item from the NHibernate collection and returns an object marked appropriately.
The approach we've taken is to have a private field that is used for the NHibernate mapping to read the data into during the DataPortal_Fetch() and then copy the references into the CSLA list after the data has been fetched. This is done in an abstract generic base class. I've included the key extract of the code below to show the idea.
This features a call to an Init() method on the BO, which allows the BO to mark itself as "old" or perform any other initialisation steps required.
Because this code lives in an abstract generic base class from which all lists inherit there's only 1 implementation of the "copy" from the IList to the CSLA list.
private void Add(IList theList)This is taken directly from the code that will be posted to CodePlex. However, we've just had to move offices at short notice and putting the code up on CodePlex has temporarily taken a back seat for a few days.
I can (at last) announce that there is now a ProjectTracker.NHibernate example solution on the CSLAcontrib site on CodePlex.
Can I suggest that all future CSLA / NHibernate questions (especially those related to the ProjectTracker.NHibernate solution) are posted on the CslaContrib forum.
Thank you all for your patience and support.
David
Just curious, how do you link this projects (csla and nhibernate) to the existing CSLA project's ProjectTrackercs?
When i donwloaded the cslacontr, I only see Test projects. Really like to see how it is actually implemented with User interfaces.
Thanks.
Sorry for the slow reply, but your email got "lost" in our system.
There is no change to the ProjectTracker UI code line. That was the point of the changes. All the changes made were "under the hood" so that the UI remained 100% the same.
Just replace the standard assemblies with the CSLA/NHibernate ones and everything should still work exactly the same.
Yes it is still there included in the release - I just checked.
I have a question about concurrency. And I admit I have only just started to look at the PTracker sample. I notice that the timestamp fields have been commented out. Is this handled by NHibernate, or am I missing something?
BTW, nice job I was just looking for an example of Csla and NHibernate.
Look for an integer Version column and field in the code. That is the way we handled optimistic concurrency the NHibernate.
I can hardly wait to see the NHibernate version of ProjectTracker!
The ironic thing is that I spent a lot of time over the weekend experimenting and learning some of the ins and outs of NHibernate and my experimentation spawned several questions on the best way to integrate it into a CSLA project. I remembered spotting this thread on this forum about a month ago and was going to ask you about the status of the ProjectTracker implementation. I was thinking I was going to do a search to find the thread and to my suprize it was at the top of the list!
Copyright (c) Marimer LLC