Where to put behaviour logic when using POCOs?

Question

I never used POCOs, so I have the habit of putting a lot of logic in my business object classes. Hence I believe I'm missing some important concepts about class-layouts, and the thought-process that is needed here.

So I would appreciate some ideas to point my brain in the right direction;

Say if you have two classes; Company and Employee. Could you give some examples of what classes you would build "around" these that take care of various behavior/validation etc.? (Like some class names, and a brief description of their purpose)

(Or any other examples would be just as useful I guess.)

score 1 · Accepted Answer · edited May 23 '17 at 12:04

1

you can put validation and business logic by creating a metadata class for that business class like this

[MetadataType(typeof(EmployeeMetadata))]
    public partial class Employee
    {
        public class EmployeeMetadata
        {
            [Required(ErrorMessage="Employee Name is Required")]
            [StringLength(50, ErrorMessage="Must be under 30 Characters")]
            public string Name { get; set; }
         }
    }

these classes are called 'buddy classes' Refer this

edited May 23 '17 at 12:04

Community

1
1

answered Jan 26 '11 at 22:05

Praneeth

2,527
5
30
47

I see, I didn't know about these attribute features. Though I forgot to say, but I was thinking about the the POCOs existing in a DAL assembly. That would not allow me to extend in this way.. – bretddog Jan 26 '11 at 22:16
you can actually extend it there would not be any problem and coming to Data Annotations you need not to do it, u can write ur custom logic in setter for proper validation... But the standard and easy way is do it as attributes.. – Praneeth Jan 27 '11 at 00:54

score 0 · Answer 2 · answered Jan 26 '11 at 21:58

I usually create a facade layer for any logical code groupings in my system. For instance let's say a user will only need to deal with company data and employee data if the user has Admin Credentials. So in that case i would create an AdminFacade class as follows:

public class AdminFacade 
{  
   public Company GetCompanyByEmployee( Employee employee )
   {
        // open a db session / web service call etc.
        // run a query to find the company by employe id.
        // populate the company object 
        // close db session
        // return the populated customer object
   } 
}

I usually have my GUI instantiate all the Facade classes and that is all what GUI deals with. You can also add validation at the start of GetCompanyByEmployee method and throw an exception if lets say employee.startdate is less than a year.

Hope that helps.

Where to put behaviour logic when using POCOs?

2 Answers2