Comments on Pete W's idea book: Architecture confusion with ORM

Roelf:Sorry for my late reply:1. Over the past yea...

2009-03-31T06:51:00.000-07:00

Roelf:

Sorry for my late reply:

1. Over the past year or so, I've learned that the AcitveRecord pattern is an elegant solution for simple persistence models, and a repository pattern requires more code but proves to be effective when dealing with more complex structures.

2. I ALWAYS place my controller and persistence logic underneath interfaces, and use something such as StructureMap, Windsor, or custom service locators to put the pieces together. Once you get the hang of using DI, it is not painful, it enforces loose coupling, and eliminates all of the dependency dilemmas I've mentioned in the article.

Other notes: You can sub-class an AR class within the same table. I usually have an abstract parent, and multiple child classes. I use a discriminator column to determine the class type of any given row.

I have some example code if you would like me to send it to you.
Pay attention to the discriminator attribute on this page:http://www.castleproject.org/activerecord/documentation/trunk/usersguide/typehierarchy.html

You CAN make an AR property private, NHibernate supports this. The trick is to make the access modifier for that property set to "field" More information look at the access modifier here:
http://www.castleproject.org/activerecord/documentation/v1rc1/usersguide/generics.html

In terms of validation, I recommend looking at the castle validator component, which allows you to write your own validation method or choose from a stack of existing validators. More information:
http://hammett.castleproject.org/?p=114

again, my apologies on the slow response, if I can help any more, let me know

Ironic?Celebrado, you bring up a very good point, ...

2009-03-31T06:40:00.000-07:00

Ironic?

Celebrado, you bring up a very good point, lumping the controller and view logic together while separating the models is definitely the best solution 99% of the time.

Unless of course you need to reuse the controller logic across different view implementations (EG use the same controllers for a web-based version as well as a thick client.) In this case, some DI using an IOC container will solve all of your problems

This article was written before MVC.NET, but after Monorail and ruby on rails frameworks gained popularity.

(ironic:on)And why not put the controller and the ...

2009-03-30T07:43:00.000-07:00

(ironic:on)And why not put the controller and the view in the same assembly? (ironic:off)

Interesting article, thanks for that. Currentyly, ...

2009-03-23T05:17:00.000-07:00

Interesting article, thanks for that. Currentyly, we have three problems implementing ActiveRecord in the way you descrived last (the free-for-all way):

- Inheritance: Thus far I didn't succeed in subclassing AR classes while still saving them in the same DB table. And no, I would not like to create different DB tables for each subclass (I like the free-for-all approach, thank you :) )

- Encapsulation: Did you ever try to make an AR property private? In other words, is it possible to save data in the DB that is only managed by the AR class itself? I didn't succeed in this also.

- Implementing Business rules (like validation) is also quite hard. Because when you call the Save function of an AR object, it is only performing data-validations, which are quite different then business-validations. And so we have to override every single Save function of AR, 'injecting' our own business-rules.

Yeah.

2009-02-12T14:29:00.000-08:00

Yeah.