Controller or LINQToSQL Wrapper. Need advice ...

[shapper]

Hello,

I have three tables: Post, PostTags and Tags.

I created a Post wrapper named: PostPaper. PostPaper has two
properties: Post and Tags. Tags are the tags associated to the Post.

When I Insert, Update or Delete a post I also need to Insert, Update
or Delete the tags associated to this.

My question is:

Should I place the Update, Delete and Insert LINQ code in my Post
wrapper (PostPaper) in my my PostController?

If I place it on my post wrapper then on my PostController I would
just have, for example: PostPaper.Inser t() ...

The other approach would be to have all code in PostController and
PostPaper would have only the properties Post and Tags.

Thanks,

Miguel

[bruce barker]

Re: Controller or LINQToSQL Wrapper. Need advice ...

generally you'd create a third component, a data adapter, that knows how
to save and fetch the objects. its best that the adapter uses the
factory/interface pattern, so the controller just knows the adapters
interface. then if in the future you need to change how the data is
saved (say you had to convert to a web service that talked to database
rather than the database due to security/firewall concerns). you would
just need to a new adapter (unit tested separately), and no other coding
changes would be required.

-- bruce (sqlwork.com)

shapper wrote:

Hello,
>
I have three tables: Post, PostTags and Tags.
>
I created a Post wrapper named: PostPaper. PostPaper has two
properties: Post and Tags. Tags are the tags associated to the Post.
>
When I Insert, Update or Delete a post I also need to Insert, Update
or Delete the tags associated to this.
>
My question is:
>
Should I place the Update, Delete and Insert LINQ code in my Post
wrapper (PostPaper) in my my PostController?
>
If I place it on my post wrapper then on my PostController I would
just have, for example: PostPaper.Inser t() ...
>
The other approach would be to have all code in PostController and
PostPaper would have only the properties Post and Tags.
>
Thanks,
>
Miguel