var blog = new ThoughtStream(me); RSS 2.0
 Wednesday, October 15, 2008

Let's say I have a small hierarchy of object: Faults and Parts. A Fault can contain many parts, and a part has no meaning without being associated to a Fault. To ensure that I have no Parts without a parent Fault, I have this basic code in place:

public class Part
{
    private Part()
    {
    }
 
    public string Description { get; set; }
 
}
 
public class Fault
{
    private IList<Part> _parts = new List<Part>();
 
    public IList<Part> Parts { get { return _parts; } }
    
    public Part CreatePart()
    {
        Part part = new Part;
        _parts.Add(part);
        return part;
    }
}

This ensures that I never have a Part in an "invalid" state - without an owning parent.

I also have a business rule that say that I'm not allowed to have a Part without a description. My typical implementation of this business rule has been in the UI layer - my Presenter would have the logic to require a user to enter a description when creating adding a part to a fault.

public class PartCreationPresenter
{
 
    Part _part;
 
    public PartCreationPresenter(Part part)
    {
        _part = part;
    }
 
    public DescriptionProvided(string desc)
    {
        if (string.IsNullOrEmpty(desc))
        {
            view.ShowDescriptionRequiredMessage();
        }
        else
        {
            _part.Description = desc;
        }
    }
 
}

Here's the question:

Should this "require a description" logic be in the UI layer (Presenter) the way I have it, or should I put it in the Part object and have an IsValid flag of some sort on that object?

I don't like having this coded in the presenter only. It makes the business rule very easy to break - create a part from anywhere else, and you can ignore this rule. But I'm not sure I like it in the Part object, because it would make the presenter difficult to code. How would I execute the specific view.ShowDescriptionRequiredMessage() method if the rule is coded in the Part?

Any opinions, suggestions, articles, etc. are very welcome. I'm very interested in hearing how other people are handling this situation.

Wednesday, October 15, 2008 10:54:12 AM (Central Standard Time, UTC-06:00)  #    Comments [2]. Trackback 
Tags: .NET | Analysis and Design | Design Patterns | Domain Driven Design | Model-View-Presenter

Monday, October 20, 2008 2:20:30 PM (Central Standard Time, UTC-06:00)
I am still battling with this issue myself. In the past we used the CSLA objects and encapsulated the logic in the entity itself. The problem with that approach is that in a different context the rule may not apply. I am almost tempted to try a theory of actually having the rule implemented in a separate class based on the context.

What I am talking about is something like:

brokenRules = PartValidator.Validate(myPart);

Where brokenRules is a collection of some defined broken rule class.

Just food for thought.

Fernando
Monday, October 20, 2008 2:44:10 PM (Central Standard Time, UTC-06:00)
that's very much the direction that i'm heading - a separate class to validate, depending on context. There's a lot of good discussion on this over at the Los Techies cross post.

I'm just trying to figure out the details, now. I've got one prototype that "works" but i dont like it. going to play with a few more ideas to see what I can come up with.
Comments are closed.
Navigation
About Me
View Derick Bailey's profile on LinkedIn

Send mail to the author(s) Contact Me
Archive
<July 2010>
SunMonTueWedThuFriSat
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2010
Derick Bailey
Sign In
Statistics
Total Posts: 115
This Year: 0
This Month: 0
This Week: 0
Comments: 44
Themes
Pick a theme:
All Content © 2010, Derick Bailey
DasBlog theme 'Business' created by Christoph De Baene (delarou)