Paul wrote:> I am doing something very similar, and for right now I do kind of need
> to keep them seperate. You got me thinking though.
>
> I have never thought about keeping only one set of models, when I
> create models in the backend proper copies are made in the frontend.
>
> Would that work for you?
As far as I can see, the problems are:
1) You need to keep the model code in sync. This may not be a problem
with the correct source control, but you also need to keep your
deployments in sync. With a DRb model publisher on one end (say, the
admin side), and a DRb client on the front-end, any changes to the model
code would be instantly available to the DRb client.
2) There''s double the amount of SQL on the wire. Given that AR
isn''t
necessarily going to be using the most efficient SQL possible, it''s
likely to be inefficient.
3) You''re repeating yourself. It may be an intangible, but it feels
far
more Railsy to have a single model definition.
The "right way" to do it would probably be to have three applications
-
one with the model at the database, which publishes its methods to the
other two, the admin and front-end apps, over a standard RPC protocol,
like SOAP or something. That would allow the front-end and back-end to
be almost completely decoupled from the data model, to the extent that
separate teams could work on them, but that looks like overkill to me.
Essentially, my problem with keeping proper copies is that it''s a
possible point of nasty failure that should be relatively simple to
completely avoid. It''s also one less thing to have to remember which,
for a numbskull like myself, is rather important...
--
Alex