How/Where to apply business rules to POCO objects?

Question

Let's say I have a POCO with the following:

    [DataMember]
    public Nullable<int> MetricId
    {
        get { return _metricId; }
        set
        {
            if (_metricId != value)
            {
                _metricId = value;
                OnPropertyChanged("MetricId");
            }
        }
    }
    private Nullable<int> _metricId;

I want to validate that the MetricId is strictly greater than 0

Obivously, if I put this rule as a data annotation in this class it will be overwritten the next time I regen the poco. Where do I put this logic?

Thanks!

Why can't you inherit from a BusinessRule class? The POCO doesn't *inherit* from either `IObjectWithChangeTracker` or `INotifyPropertyChanged`, those are interfaces that it implements. Implementing an interface doesn't prevent you from inheriting from a base class. — Joel C, Apr 12 '11 at 19:15
You're right. I was mistaken. It would still be overwritten on generation though. I updated my question. — O.O, Apr 12 '11 at 19:20
If you're using POCO, you can either edit the T4 template to add the inheritance in the code generation, or use a partial class as mentioned below. — Joel C, Apr 12 '11 at 19:22
Is this helpful? http://stackoverflow.com/questions/5128303/how-to-add-validation-to-my-pocotemplate-classes/5128373#5128373 — Ladislav Mrnka, Apr 12 '11 at 19:37
@Ladislav - It's worrisome that you consider it a "trick". However, it is helpful. Thanks. — O.O, Apr 12 '11 at 19:45

score 6 · Accepted Answer · answered Apr 12 '11 at 18:59

6

I seem to remember the suggestion being to utilize partial classes and roll a partial class that implemented the logic you didn't want to be overwritten.

answered Apr 12 '11 at 18:59

Khepri

9,547
5
45
61

Are partial classes supposed to be used in this way? Feels hackish, doesn't it? Also, based on my limited understanding of partial classes, they are limited in what they can support. – O.O Apr 12 '11 at 19:04
In general, I agree. I'm not a huge fan of partial classes, but in a scenario like this, I do believe they make some sense. When you have code that is auto-generated that you have limited control over, you need a way to persist the "other" changes that you want without losing them every time. In such a scenario, I can see a benefit to partial classes. I'm not saying this is the best or only way, but I do know I've seen this approach recommended prior. I'll try to dig deeper if I have some time this afternoon. – Khepri Apr 12 '11 at 19:12
2

That's exactly how partial classes are supposed to be used. That was also why partial methods were introduced; the code-generated partial class can have the partial method declaration, and you can choose whether or not to give it an implementation in your side of the partial class. – Joel C Apr 12 '11 at 19:13
I'm going to give partial classes a try. I can also implement my solution if it doesn't work out. – O.O Apr 12 '11 at 20:30
To back up what @Joel C said, here's an MSDN discussion of partial classes: http://msdn.microsoft.com/en-us/library/wa80x488%28v=vs.80%29.aspx. Even though generated code is the second reason listed, by all accounts it's the primary reason for their existence. – Justin Morgan - On strike Apr 13 '11 at 13:41

score 0 · Answer 2 · answered Dec 12 '12 at 01:31

It's not clean using partial classes lets say you have product abstract lass and derived classes online product and store product. Both inherit price property but price is different. And let's say business logic may be different too. Now you got two additional classes that you don't really need. In larger system, it multiplies.

O.O · Answer 3 · 2011-04-12T20:04:22.540

0

After reading the comments and responses, it seems that creating another class is fine, but by making it partial, it ties my business logic directly to the Entity Framework and the generated POCO code. This is worrisome because as EF4 changes into EF5 and the T4 template changes to the T5 template what will happen to my code? Plus I just don't feel comfortable using partial classes as normal classes.

Instead, and someone can still provide a better answer (please do), I think creating a framework independent object (one not tied to EF) is better. Then I can map it to a generic business object. Something like:

    static Customer Map(CustomerPOCO poco)
    {
        return new Customer
        {
            CustomerId = poco.CustomerId
            ...
            ...
        };
    }

edited Apr 12 '11 at 20:04

answered Apr 12 '11 at 19:56

O.O

11,077
18
94
182

1

FYI, T4 stands for Text Template Transformation Toolkit, it's not tied to a version of Entity Framework or .NET. The only way it would become T5 is if Microsoft comes up with another word starting with "T" to put into the name ;) – Joel C Apr 12 '11 at 20:05
1

I'm not sure I understand what you're so worried about. Partial classes are perfect for fine tuning auto generated code and I think that's what they were intended for. – Pete Apr 12 '11 at 20:08
3

Your preference for using partials is entirely your own but please be clear that you are in no way being tied to EF by using partial classes. You aren't even tied to the T4 template should you choose to refactor away from EF in the future. It is a POCO that just happens to have been generated by a template. You're just creating a whole lot of unnecessary mapping work for yourself with this solution imo (even if you do use AutoMapper). – Darren Lewis Apr 12 '11 at 20:09
2

Unless you edit the default T4 template, you're using partial classes whether you want to or not. All the classes are generated as partial classes regardless of whether you choose to define anything additional in a separate file. – Joel C Apr 12 '11 at 20:12

How/Where to apply business rules to POCO objects?

3 Answers3