Hello,
Im not yet using the CSLA.NET framework, but im just researching if it's smart to do so. Our current application is very large builded in pascal and ported to delphi. It's an business to business application including: customer management, insurances, financials and alot of other stuff u can think about. With over 1200 tables, 1000 data entry screens / forms, 200 reports and ofcourse alot of "behind the screen" functionality.
We created a small .NET application but used an ORM named Opf3 to create a data model in Objects. This application can now use those objects as being a repository. Working great! Except that the entities are data-entities and not business-entities.
The bad thing is that the database is Pervasive, and in the past people desided to disable the foreign keys etc, the legacy delphi application is using BTrieve API instead of SQL to access the tables. It's very frustrating to bump into so many database problems :(
But anyhow our management desided not to migrate, but to build a new application against the current database but keeping in mind we should switch to another database whenever the new application is large enough. With no BIG-BANG scenaro :)
Anyway, my real question is about what Rockford Lhotka said about "object factory model" being better when using an ORM tool. In which CSLA.NET version is the object factory model available? Which book will describe more about it? Are there any good examples in how to use the object factory model? How is it related to several DAO's? So many questions ;)
Greetings,
Raymond de Jong
I think the object factory is available in 3.6.
However, I'ved used CSLA with an ORM since 2.1. It really comes into play only when fetching a single object, not a list. When you're fetching a list, you get to populate it anyway you want.
The workaround I used for fetching a single object was to (1) fetch an obect with the data in it using the ORM, and (2) copy the data from the fetched object to the one CSLA was asking me to populate. It was a little awkward, but it works fine.
hmm, but 3.6 is a beta version and not proven yet "in the real world"? Does anyone know when it's going to be released as an official version? Rockford? :)
I wonder why Rockford says the Data Portal way isn't suitable enough when using an ORM, or from the other side.. why the Object Factory should be used when using an ORM.
rsbaker0 u say it's possible and it works, but do u know if unittesting using a data portal is possible and what happens after transfering the business object between the business tier to a client tier. I guess it can't always access the data-tier when it's across the data-tier boundaries. I've no experience with WCF yet so maybe "Lazy Loading" will still be possible no matter where the Business Object is at that moment. I just want to avoid using any DTO technique, as less mapping as possible :)
I will try to explain the ObjectFactory and how that relates to
the ORM tools.
One of the major differences between Csla objects and other
business object frameworks is that each Csla object is “mobile object”.
What does that mean? It means that the object is constructed in one context,
lets say application server, but also used in another – client/ui
context. Object exits in both places, csla takes care of necessary
serialization – transporting object back and forth for you.
But what does that mean for you as a developer. There is
one major constraint – you cannot construct the object directly on the
client. Hence the use of Factory Method pattern and more important
DataPortal. We request an instance of the Csla object from the data
portal, which constructs it for us on the server and then serializes it to the
client for us.
Every ORM framework that maps the db object to “entities”.
Lets presume that the entity we want to generate is the Csla object. That
means that ORM framework has to have a way of accessing your method of
constructing an object.
NHIbernate and MS Entity Framework are the two ORM frameworks I
am familiar with. The problem in Csla world is telling the ORM framework
how to construct Csla entity. Since DataPortal constructs Csla object
that generally means making ORM somehow aware of DataPortal. That is
where the ObjectFactory comes in. It plugs directly into DataPortal
creation/retrieval process and allows us to substitute Csla own object creation
process with our own factory that is integrated into ORM. And that is the
purpose of the ObjectFactory.
As you have mentioned the ObjectFactory is a part of Beta 3.6
release, but if you take a look at the NHIBERNATE example on CslaContrib
project, hosted on CodePlex, you will see that it uses an ORM tool
without the need for ObjectFactory. They found a different approach to go
around a DataPortal issue. So – no ObjectFactory is not necessary
for integrating Csla with an ORM.
Nermin
From: rfcdejong
[mailto:cslanet@lhotka.net]
Sent: Wednesday, October 15, 2008 7:38 AM
To: Nermin Dibek
Subject: Re: [CSLA .NET] Opf3 as an ORM together with CSLA
hmm, but 3.6 is a beta version and not proven yet "in the real
world"? Does anyone know when it's going to be released as an official
version? Rockford? :)
I wonder why Rockford says the Data Portal way isn't suitable enough when
using an ORM, or from the other side.. why the Object Factory should be used
when using an ORM.
rsbaker0 u say it's possible and it works, but do u know if unittesting
using a data portal is possible and what happens after transfering the business
object between the business tier to a client tier. I guess it can't always
access the data-tier when it's across the data-tier boundaries. I've no
experience with WCF yet so maybe "Lazy Loading" will still be
possible no matter where the Business Object is at that moment. I just want to
avoid using any DTO technique, as less mapping as possible :)
^^^
I think this may be overcomplicating things.
The only ORM related issue I ran into was that my particular ORM will not allow you to populate the values of the object "in place" -- it wants to create the object for you.
It turns out, incidentally, that NHibernate allows you to do exactly that -- it's perfectly happy to allow someone else to construct the empty object for you-- exactly what happens in the default DataPortal_Fetch implementation with CSLA -- and then allow NHibernate to fill the values. So, for NHibernate, you don't even need a special factory implementation.
My ORM constructs and fetches at the same time, so it can construct a CSLA object server side, but I have no direct way of "returning" this object when CSLA has provided me with an empty object to fill out. So, I get around this just by copying the fields from the object fetched by the ORM to the one CSLA wants populated. I'd prefer not to have to do this for performance reasons, but it only comes into places with individual object fetches, not list object fetches.
DataPortal_Fetch executes on the server side of the Data Portal by default, so any fetching will occur on the server whether you use an ORM or not.
It's only sad to see that there isn't much documentation about the "Object factory model" yet.
A guy called "Alfred Ortega" did found a link for me:
http://www.lhotka.net/weblog/CSLANETObjectFactoryAttribute.aspx
But that is all i have at the moment.
Is it smart to start the new application with 3.5, or start with 3.6..
- it will be a 3 or 4 tier application mainly focussed at windows (but using WPF)
- using Opf3 as ORM
I guess that only Rockford can answer this question :)
This post was a while ago, and i know alot more about the Object Factory.
Ryann Kelley's source code on google helped alot, it's not hard to understand. Except that he didn't use DTO's and that's exactly what we want to use..
I'm still trying to find a way to write a "generic piece of framework code" just to fill the properties of an CSLA business object. Each business object would have an mapper object which knows how to fill the properties with properties from the DTO.
Anyway i see Ryann Kelly stept away from CSLA :(
http://www.techfocus2.com/2008/11/csla-first-base-was-fun-but-i-want-a-relationship/
rfcdejong:
I'm still trying to find a way to write a "generic piece of framework code" just to fill the properties of an CSLA business object. Each business object would have an mapper object which knows how to fill the properties with properties from the DTO.
That is exactly what the DataMapper class in CSLA is for.
Very useful!
Joe
sorry, i didn't had the time to reply yet.
gladly u did found the link yourself :)
I'm trying to find a example for using CSLA 3.6 object factory combined with DTO.
Our DTO would be an Opf3 data entity object, completely seperated from the business.
But im not sure if we should let the data layer knows about the business objects.
On the other side the business objects don't know about the datalayer.
Only the factories are allowed to know.
I hope we don't need to write a factory for each business object.
But about the DataMapper... it's using a DataMap for the property definition, i'll look more into that.
I don't want to use reflection myself with the differend kind of possible exceptions.
Greetings,
Raymond de Jong
Copyright (c) Marimer LLC