@RemiC Hi, really nice package. have started implementing it on a new side project and so far it feels really natural :) Just a question. Is there some way to not have the value objects be mutable? So far as i can tell there is now way now to make the value objects and entities immutable?

@matthisstenius : Thanks :)

You can make an Entity/ValueObject immutable by using a custom class that implements the Mappable interface (or use the Mappable trait), instead of extending the base class. This way you can implement getters/setters in any way you want.

Also, I'm on my way of simplifying this process, as right now you have to implement 4 methods for the Mappable interface :

public function setEntityAttributes(array $attributes);
public function getEntityAttributes();
public function setEntityAttribute($key, $value);
public function getEntityAttribute($key);

Which is redundant and I found that when I wanted to use protected attributes for an Entity's columns instead of a $attributes array, things could get tough :)

On next update it will be shorten down to 2 methods :

public function setEntityAttributes(array $attributes);
public function getEntityAttributes();

Which will make custom implementation far much simpler.

@RemiC Cool! Thanks ;) Will play around with it a bit and see if i can come up with something that works.

@RemiC There is a problem with the auth driver with analogue orm > 2.1.4. Try to call Mapper::repository() which is not static :(

@pmall : i refactored the analogue manager to use DI over static calls, so the auth wasn't up to date. Fixed in last version.

@RemiC great thanks :)

Looks great. I think Active Record is an anti-pattern.

I would really like it if someone could do a write up or something explaining the benefits of this over just using eloquent. I've been reading the wiki etc and it hasn't clicked for me yet. What advantages do I get? What disadvantages? Anybody that could point me to a good article or something that would be fantastic.

@isaackearl the difference is in the use of the Data Mapper pattern for managing models.

With Active Record (Eloquent) every row in your database tables maps directly to an object. With Data Mapper (Analogue) and object can be composed of different rows in different tables.

Imagine you have both enterprise and personal customers. You wouldn't want to store their info in the same table but at the same time, they are your clients. Like the next little schema:

+-----------+-------------+
| Client ID | Client Type |
+-----------+-------------+

+-----------+------------+-----------+
| Client ID | First Name | Last Name |
+-----------+------------+-----------+

+-----------+--------------+
| Client ID | Company Name |
+-----------+--------------+

If you wanna retrieve all of your customers data using eloquent you'd neet to use polymorphic relationships and have special fields on each table. With Data Mapper you'd only need to tell your object to retrieve the data from different tables depending on the client type.

There is a great podcast about the differences, advantages and dissadvantages of both: http://www.devdiscussions.com/episodes/6259-episode-2-activerecord-and-datamapper

thanks @carkis .

I really wish I had known a bit more about data-mapper before starting my most recent project. I have alot of polymorphic relationships and things that would probably be better suited for a data-mapper type orm...

So ever since I saw this thread I started realizing how a data mapper orm might be better suited for the things I'm doing, and I've been doing more research on this type of pattern. I'm wondering here if someone who has tried this package and have good experience with data-mappers in general might be able to tell me why I should use Analogue instead of implementing something like Doctrine 2, which has been around for awhile, and is considered a pretty powerful data mapper. Does doctrine 2 have alot of features that Analogue doesn't have yet? Thanks

@isaackearl try Analogue. It is very eloquent like. Doctrine is a huge beast.

I'm hoping for single table and multi table inheritance. Can I do them with analogue? I didn't see anything in the wiki about it.

Table inheritance ? There must be a better way ;)

@pmall I understand that for 80-90% of scenarios eloquent has enough tools to do basically anything I want. However that is not the case for one of the projects I'm working on. I need something more flexible/powerful. Surely you aren't saying that there are no use cases for table inheritance?

i think i get what analogue is but can someone explain why you wouldnt use this for every project?

what i like to do is create standard predefined objects for data and fill those with data from sources. so the source of the data doesnt matter, eg: database / api / session.

i like this approach because then you can always know for sure what data is in the predefined object and how it is arranged. you could think of it as an adapter... an extra layer between data source always insures you get the data you expect in a predefined format.

i see sometimes in legacy systems that for example you get a product/category list back and depending on the source its internal structure arrangement is different then getting it from another source... this is very frustrating.

so for example a session with a cart that returns all values in a different order then for example getting an old cart from the database or api.

does this make sense?

isn't analogue a tool just like this or did i misunderstand?

are there also drawbacks to this?