Employee is not a good class at all... Employees have different functions, different working hours, different policy, etc.
I would either make a virtual class Employee which would have to be derived or IEmployee interface, both works great and application can be easily enhanced and maintained. Code is more reusable, too. "If design is wrong, don't think that the final app will be better" 2010/3/8 Jamie Fraser <[email protected]> > Personally I would have > > POCO class - i.e. Employee, which contains properties and not a lot more. > > Service/Factory/Repository (as required) - EmployeeRepository, > EmployeeFactory etc. This will hydrate, add, delete your Employee classes. > > I wouldn't put your "add employee" logic into your Employee class, because > it doesn't really belong there. > > > On Sun, Mar 7, 2010 at 11:54 PM, raringsunny <[email protected]>wrote: > >> Thanks for a response Vipin. >> >> On Mar 7, 2:00 pm, crazy <[email protected]> wrote: >> > I think, you can store all the property varibales in a seperate class >> and >> > serialize that class and u can create a generic list of this class for >> > moving data from one layer to another layer and also u can inherit this >> > class for other scenarios like EmployeeSalary or EmployeeLeave etc... >> > >> > I dont know is there anything wrong in this Logic.. >> > >> > Thanks >> > Vipin! >> > >> > >> > >> > >> > >> > On Sun, Mar 7, 2010 at 9:43 AM, raringsunny <[email protected]> >> wrote: >> > > Thanks for responding Brandon. >> > >> > > One advantage I see in having a separate class is that if I serialize >> > > my properties class into XML, I can then send that XML object to the >> > > database procedure. Using OpenXML, it would be easier to store the >> > > information in the database. >> > >> > > I am seeking more ideas on what is the best way to do it? Is there any >> > > downside If I serialize a class which also contains method >> > > definitions? >> > >> > > On Mar 7, 12:27 am, Brandon Betances <[email protected]> wrote: >> > > > tl;dr: I wouldn't do it. >> > >> > > > Well I think your confusing yourself. You* *say you made a class >> called >> > > > Employees, and then ask if you should make 2 classes; what I *think >> *your >> > > > getting at is a making a partial class, and containing methods >> inside its >> > > > own class *file*. In that case, if thats how you want to do it, >> there is >> > > no >> > > > effect on the class when its compiled, that I know of. Really, >> there's no >> > > > sense in making a completely separate class to perform work on the >> > > > properties of another class. Then you'd have a problem with >> instances of >> > > the >> > > > class, when you could just do the work in the one single *current >> > > *instance >> > > > of the class. >> > >> > -- >> > "People who never make mistakes, never do anything." >> > >> > dEv >> > >
