1) I am curious to see how SS would support a scenario where an already existing datamodel has to be used as the basis. It seems a bit odd having to start with defining php classes as a means to establish data relationships. Second a datamodel is more than just relationships, constraints for instance should be considered part of it.

2) When working with an existing datamodel, it looks like accessing the data services would be done from the controller classes. Please comment.

3) Where does the DataObject class originate from? Is it a Silverstripe class? It does not seem to make much sense to hardwire the business objects to a vendor specific class. Please comment.

4) How is persistency handled and more specifically how are transactions handled? What control does one have over this?

Hi lolke,

1) I am curious to see how SS would support a scenario where an already existing datamodel has to be used as the basis. It seems a bit odd having to start with defining php classes as a means to establish data relationships. Second a datamodel is more than just relationships, constraints for instance should be considered part of it.

It is a little odd - I am used to SQL scripts to define the db and any changes to it, but I must say sapphire is very nice to use, especially some of the features of defining the model...

$price = $product->price;//field
$source = $product->source();//relating object
$locations = $product->locations();//relating objects

the last two statements are written very neatly, but actually perform a joins and return relating object(s).

2) When working with an existing datamodel, it looks like accessing the data services would be done from the controller classes. Please comment.

If "data services" means "business logic" or operations to read/process/update the data then yes... you need to write code somewhere to operate on the data - MVC is s nice architecture (or if you have been around for a while the three-tier architecture) the alternative I am guessing is to write your application in something like PL/SQL...

3) Where does the DataObject class originate from? Is it a Silverstripe class? It does not seem to make much sense to hardwire the business objects to a vendor specific class. Please comment.

a quick search of the downloaded code would tell you that yes it is a ss class sapphire\core\model\DataObject.php.
My comment would be that it is standard practice to pick a database access library rather than coding your own one from scratch (which no-one is stopping you from)

4) How is persistency handled and more specifically how are transactions handled? What control does one have over this?

Transactions, within mysql are off by default, please see here... http://silverstripe.org/data-model-questions/show/288434#post288434

Barry

Hi Barry,

Thanks a lot for your response! Please find some additional comments further down this post.

ad 1)

I can appreciate that a framework is used to access the data in a logical way. However defining the datamodel is another thing.

ad 2)

Data Services means the logical operations on the Data Layer (allowing reading, writing data). This does not include business logic. Business logic would reside in the layer above (multi-layer architecture). I know MVC well (I've worked as a software architect and have an MSc. IT and 15+ years experience with OO design and C++/Java). Having an existing datamodel and making (part of it) accessible through a web page is a typical scenario I would be interested in.

ad 3)

Well, I am not saying that you should code one from scratch, not necessarily. However hard-wiring by inheritance is another ballgame. I would rather see an approach in which I can fully separate persistency from business logic and use alternative more loosely coupled design pattern instead (e.g. by means of association). E.g. I could imagine having a class Person and a class PersistentPerson adding the persistency to a Person. It would be perfectly fine to have PersistentPerson inherit from DataObject. PersistentPerson could be generated instead of hand-coded. In the past I've designed and written a framework that was designed along these lines.

ad 4)

I would require transactions in some scenarios where a user actually performs a logical transaction. That is registring, making an order and a payment. As soon as creation of more than 1 entity is involved I would like to see that either all or none are created. That's the whole point isnt it?

Again thanks for taking the time to help! Its much appreciated.
Kind regards,
Lolke

BTW Part of my dissertation was dedicated to handling data and data access patterns. If you like I can send you a link.

Hi lolke,

Good points. On #2 Business logic in SilverStripe's case should be tied to your model (i.e your Article class) rather than the controller. However you will find a bunch of places where people haven't made the distinction between the two which can often lead to confusion. Your controller should only perform URL based operations (eg perhaps handling CRUD operations) or other template functionality rather than dedicated business logic.

#1 The ORM is just a nice straight forward way help users with the idea of fields / objects, how it is implemented makes it relatively straight forward to understand and fast to implement where as adding another layer would only decrease the readability.

#4 Most of the core hasn't yet been rewritten with transactions and constraints in mind yet (since only recently moving from mysql so those are luxuries!) but you can do this in your custom code with DB::getConn()->startTransaction(). Please note that for transaction support you will have to use the Postgresql module or SQLite. For more information on transactions see the PostgreSQL module for methods.

#2 =>
Business Logic in my opinion should always be tied to the model. That is, the model 'encapulates' the business rules and policies; its it's primier responsibility. So we agree on that, I believe.
#1 =>
Still, a different thing is hard-wiring a business object to a DataObject class. Architecturally it makes no sense. However from a viewpoint of ease of use of the framework for less experienced software engineers its indeed slightly easier to use when developing a model from scratch. Nevertheless, when porting an existing model to SilverStripe, its much easier to de-couple the two. It also promotes reusability.
#4=>
Why is it that the use of transactions would require PosgreSQL or SQLite? MySQL has transaction support since v. 5.x?

lolke - SS has not implemented MySQL transaction specific commands yet so its an SilverStripe implementation of MySQL limitation as like you said MySQL does support Transactions. If you want to use MySQL with transactions you will have to implement this yourself.