You can declare the set accessor of your primary key property as internal so
that only classes in your assembly can modify it. If your DTO and DAO are
not not in the same assembly, you can use the InternalsVisibleTo attribute
to expose it to the assembly containing the DAO.
public class Employee
{
public int ID
{
get { return _id;}
internal set { _id = value;}
}
public string FirstName
{
get { return _firstName;}
set { _firstName = value ?? string.Empty;}
}
}
On 6/9/07, Miika Mäkinen <[EMAIL PROTECTED]> wrote:
Sorry about the format, using my phone to send this... Question below
(hopefully)
---------- Forwarded message ----------
From: Miika Mäkinen <[EMAIL PROTECTED]>
Date: Sat, 9 Jun 2007 14:43:39 +0700
Subject: DTO DAO Design
To: [EMAIL PROTECTED]
Hi all. I haven't written to this list before, i hope i am in right
place. I am quite new to distributed enterprise app architecture and i
am hitting a wall here. How do you usually do your dto objects so that
you both can allow creation on client side and ensure client does not
change properties like primary key id? I would like to keep the dto
decoupled from data access, so csla type design is not what i like.
This also leaves out internal constructors. Is there anything else but
accessing private fields with reflection? This is not favored either
as i am wishing to use ibatis as or mapper and i don't think
reflection is even possible with it. Am i missing some perfect
pattern? I am just so confused why functionality required by
practically any app needs to be so cumbersome to achieve!
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
--
Sébastien
www.sebastienlorion.com
