When I use Web (MVC), I always to create a separate classes layer. These classes often the same as DTO classes, but with attributes like [Display(Name = "Street")] and validation. But for web api Display attributes are not necessary, validation can be used by FluentValidation. Should Api controller returns ViewModels classes or DTO classes will be fine too?
the answer, as always is .... it depends.
If your API is serving multiple clients , apps etc, then returning DTOs is a better options.
ViewModels are specific to the MVC client and should already be prepared for display, meaning the data should already be formatted in a specific way, some fields maybe combined, they should satisfy whatever requirements the display pages have. They are called ViewNodels for a reason. The point is that they are rarely exactly the same as the data the API returns, which should be a bit more generic and follow a certain pattern to make sense to its users.
If your ViewModels are exactly the same and you only have one client then it's up to you if you want to create a set of duplicated classed just to avoid having the attributes.
Mapping from DTO to ViewModel and viceversa is not exactly complicated, but the process does introduce one more complication, one more layer.
Don't forget one thing though. API DTOs are supposed to return the data they have on any entity regardless of the requirements of any UI. Requirements can change anyway, new fields added or discarded. You're more than likely to leave the API alone when that happens and simply change your ViewModels.
Your ViewModels are specific to a UI page and should contain only the data required by that page. This means that you can end up with multiple ViewModels for the same data, it's just that the display requirements are different for each.
My vote goes towards keeping the ViewModels and DTOs separate, even if, at this point in time they are exactly the same. Thins always change and this is one of those things you can actually be ready for.
Actually it depends on application's architecture how we want to return response. In this case yes we can return DTO classes but i think that would not be the good approach because we should create a separate Resource classes that will map with DTO and then return. Just see the below example:
public class CustomerDTO
{
public int ID { get; set; }
public string Name { get; set; }
public int DepartmentId { get; set; }
}
public class CustomerResource
{
[JsonObject]
public string Name { get; set; }
[JsonObject]
public string Department { get; set; }
}
Suppose we have CustomerDTO class and we want to return response in the following json format
{
"name":"Abc xyz",
"department":"Testing"
}
So in this case we should we have separate class that will return as a response to the end user as i created CustomerResource. In this scenario we will create a mapper that will map DTO with resource object.
And also with this implementation we can test resources independently
In Symfony 3, how would you differentiate the following based on Domain Driven Design (DDD)?
Service (the one that is defined in config service file)
Doctrine Repository (\Doctrine\ORM\EntityRepository)
Entity (a class in entity folder)
I'm aware that doctrine is decoupled from Symfony (i.e. it can be completely omitted). But then which one is the repository in a Symfony project without Doctrine? Or perhaps Symfony (without Doctrine) is actually not really following DDD ?
Edit
I try to mock up a scenario below to make my question clearer
A controller has a function to return all available managers for a project
class ManagementController
public function getAvailableManagers(Array $project)
{
...
}
}
Available managers means that they have no projects on their hand and the project falls within their specialised domain (e.g. customer service, business relations, logistics, etc)
However due to poor design, the speciality domain is not stored in the database but instead needs to be called to a separate HR system via API call. Later on it will be integrated to the database
I would have thought (feel free to correct me) that the Manager should be a repository class because it currently get its information from 2 different sources. The question is ... should I use Doctrine Repository for this? Or maybe it should be just a normal entity or a perhaps a service?
class ReplacementInstructionRepository extends \Doctrine\ORM\EntityRepository
{
private $id;
private $name;
private $speciality;
private $projects;
}
I need a guide on how to split this. Thank you
Cheers,
Although I don't understand well the question, here you have some examples of projects applying DDD principles with Symfony.
https://github.com/PhpFriendsOfDdd/state-of-the-union/blob/master/README.md
EDIT
After your last description I think I can give a better answer :-).
I would say that the Specification Pattern fits well in your scenario. Specification Pattern allows you to keep business rules in your Domain layer. In this case you mentioned an important business rule:
Available managers means that they have no projects on their hand and the project falls within their specialised domain (e.g. customer service, business relations, logistics, etc)
In this case, you mentioned a poor design we need to deal with. In a greenfield project I would save the manager's specialised domain within the manager, so everything would live within the same Aggregate Root, the Manager.
In your case, I would integrate the external party (HR system) via Repository like you can see below:
nampespace xxx\infrastructure\persistence
class ManagersRepository
{
public function __construct(HrApiClient $apiClient)
{
$this->apliClient = $apiClient;
}
public function findWithoutProjects()
{
$sqlQuery = //find all managers without project
$managers = $this->execute($sqlQuery);
foreach ($managers as $manager) {
$projects = $this->apliClient->findProjectsOfManagerId($manager->id());
$manager->specialisedIn($projects); //This should be done with reflection
}
return $managers;
}
public function selectSatisfying(Specification $specification)
{
return $specification->satisfyingElementsFrom($this);
}
}
namespace xxx\Domain
class ManagersAvailableSpecification implements Specification
{
public function __construct($aNewProject)
{
$this->aNewProject = $aNewProject;
}
public function isSatisfiedBy($manager)
{
// business rules here...
if ($manager->isSpecialisedIn($this->aNewProject)) {
return true;
}
return false;
}
public function satisfyingElementsFrom(ManagersRepository $managersRepository)
{
$managers = $managersRepository->findWithoutProjects();
return array_filter(
$managers,
function (Manager $manager) {
return $this->isSatisfiedBy($manager);
}
);
}
}
Notice that the first class, as it is an concrete implementation of the repository (using MySql, Postgre, etc), lives in the infrastructure layer. While the second one, as it depends just on interfaces it lives in the Domain along with the business rules that defines an available manager.
Now you can have a Service like:
class FindAvailableManagersService
{
private $managersRepository;
public function __construct(ManagersRepository $managersRepository)
{
$this->managersRepository = $managersRepository;
}
public function execute(FindAvailableManagersRequest $request)
{
$managersAvailable = $this->managersRepository->selectSatisfying(
new ManagersAvailableSpecification($request->project())
);
return $managersAvailable;
}
}
Notice also that if in the future you migrate the specialized domains from the third party to your own database, you just need to modify one class but nothing else gets touched :-)
The question is ... should I use Doctrine Repository for this?
I think this is the most classic misunderstanding related to DDD. The ORM respository and entity is completely different than the DDD repository and entity. They just have the same name but that's all, you should not confuse them.
The DDD entity lives in the domain and does not depend on classes outside of the domain. The DDD repository interface is defined in the domain and the implementation is in the infrastructure and can depend on other parts of the infrastructure. So to implement the DDD repository interface you can use an ORM repository if you want, but you can use completely different data storage solutions than relational databases, for example noSQL databases.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am deciding if I should use a Rich Domain Model over an Anemic Domain Model, and looking for good examples of the two.
I have been building web applications using an Anemic Domain Model, backed by a Service --> Repository --> Storage layer system, using FluentValidation for BL validation, and putting all of my BL in the Service layer.
I have read Eric Evan's DDD book, and he (along with Fowler and others) seems to think Anemic Domain Models are an anti-pattern.
So I was just really wanting to get some insight into this problem.
Also, I am really looking for some good (basic) examples of a Rich Domain Model, and the benefits over the Anemic Domain Model it provides.
The difference is that an anemic model separates logic from data. The logic is often placed in classes named **Service, **Util, **Manager, **Helper and so on. These classes implement the data interpretation logic and therefore take the data model as an argument. E.g.
public BigDecimal calculateTotal(Order order){
...
}
while the rich domain approach inverses this by placing the data interpretation logic into the rich domain model. Thus it puts logic and data together and a rich domain model would look like this:
order.getTotal();
This has a big impact on object consistency. Since the data interpretation logic wraps the data (data can only be accessed through object methods) the methods can react to state changes of other data -> This is what we call behavior.
In an anemic model the data models can not guarantee that they are in a legal state while in a rich domain model they can. A rich domain model applies OO principles like encapsulation, information hiding and bringing data and logic together and therefore a anemic model is an anti pattern from an OO perspective.
For a deeper insight take a look at my blog https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/
Bozhidar Bozhanov seems to argue in favor of the anemic model in this blog post.
Here is the summary he presents:
domain objects should not be spring (IoC) managed, they should not have DAOs or anything related to infrastructure injected in them
domain objects have the domain objects they depend on set by hibernate (or the persistence mechanism)
domain objects perform the business logic, as the core idea of DDD is, but this does not include database queries or CRUD – only operations on the internal state of the object
there is rarely need of DTOs – the domain objects are the DTOs themselves in most cases (which saves some boilerplate code)
services perform CRUD operations, send emails, coordinate the domain objects, generate reports based on multiple domain objects, execute queries, etc.
the service (application) layer isn’t that thin, but doesn’t include business rules that are intrinsic to the domain objects
code generation should be avoided. Abstraction, design patterns and DI should be used to overcome the need of code generation, and ultimately – to get rid of code duplication.
UPDATE
I recently read this article where the author advocates of following a sort of hybrid approach - domain objects can answer various questions based solely on their state (which in the case of totally anemic models would probably be done in the service layer)
My point of view is this:
Anemic domain model = database tables mapped to objects (only field values, no real behavior)
Rich domain model = a collection of objects that expose behavior
If you want to create a simple CRUD application, maybe an anemic model with a classic MVC framework is enough. But if you want to implement some kind of logic, anemic model means that you will not do object oriented programming.
*Note that object behavior has nothing to do with persistence. A different layer (Data Mappers, Repositories e.t.c.) is responsible for persisting domain objects.
When I used to write monolithic desktop apps I built rich domain models, used to enjoy building them.
Now I write tiny HTTP microservices, there's as little code as possible, including anemic DTOs.
I think DDD and this anemic argument date from the monolithic desktop or server app era. I remember that era and I would agree that anemic models are odd. I built a big monolithic FX trading app and there was no model, really, it was horrible.
With microservices, the small services with their rich behaviour, are arguably the composable models and aggregates within a domain. So the microservice implementations themselves may not require further DDD. The microservice application may be the domain.
An orders microservice may have very few functions, expressed as RESTful resources or via SOAP or whatever. The orders microservice code may be extremely simple.
A larger more monolithic single (micro)service, especially one that keeps it model in RAM, may benefit from DDD.
First of all, I copy pasted the answer from this article
http://msdn.microsoft.com/en-gb/magazine/dn385704.aspx
Figure 1 shows an Anemic Domain Model, which is basically a schema with getters and setters.
Figure 1 Typical Anemic Domain Model Classes Look Like Database Tables
public class Customer : Person
{
public Customer()
{
Orders = new List<Order>();
}
public ICollection<Order> Orders { get; set; }
public string SalesPersonId { get; set; }
public ShippingAddress ShippingAddress { get; set; }
}
public abstract class Person
{
public int Id { get; set; }
public string Title { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string CompanyName { get; set; }
public string EmailAddress { get; set; }
public string Phone { get; set; }
}
In this richer model, rather than simply exposing properties to be read and written to,
the public surface of Customer is made up of explicit methods.
Figure 2 A Customer Type That’s a Rich Domain Model, Not Simply Properties
public class Customer : Contact
{
public Customer(string firstName, string lastName, string email)
{
FullName = new FullName(firstName, lastName);
EmailAddress = email;
Status = CustomerStatus.Silver;
}
internal Customer()
{
}
public void UseBillingAddressForShippingAddress()
{
ShippingAddress = new Address(
BillingAddress.Street1, BillingAddress.Street2,
BillingAddress.City, BillingAddress.Region,
BillingAddress.Country, BillingAddress.PostalCode);
}
public void CreateNewShippingAddress(string street1, string street2,
string city, string region, string country, string postalCode)
{
ShippingAddress = new Address(
street1,street2,
city,region,
country,postalCode)
}
public void CreateBillingInformation(string street1,string street2,
string city,string region,string country, string postalCode,
string creditcardNumber, string bankName)
{
BillingAddress = new Address (street1,street2, city,region,country,postalCode );
CreditCard = new CustomerCreditCard (bankName, creditcardNumber );
}
public void SetCustomerContactDetails
(string email, string phone, string companyName)
{
EmailAddress = email;
Phone = phone;
CompanyName = companyName;
}
public string SalesPersonId { get; private set; }
public CustomerStatus Status { get; private set; }
public Address ShippingAddress { get; private set; }
public Address BillingAddress { get; private set; }
public CustomerCreditCard CreditCard { get; private set; }
}
One of the benefit of rich domain classes is you can call their behaviour (methods) everytime you have the reference to the object in any layer. Also, you tend to write small and distributed methods that collaborate together. In anemic domain classes, you tend to write fat procedural methods (in service layer) that are usually driven by use case. They are usually less maintainable compared to rich domain classes.
An example of domain classes with behaviours:
class Order {
String number
List<OrderItem> items
ItemList bonus
Delivery delivery
void addItem(Item item) { // add bonus if necessary }
ItemList needToDeliver() { // items + bonus }
void deliver() {
delivery = new Delivery()
delivery.items = needToDeliver()
}
}
Method needToDeliver() will return list of items that need to be delivered including bonus. It can be called inside the class, from another related class, or from another layer. For example, if you pass Order to view, then you can use needToDeliver() of selected Order to display list of items to be confirmed by user before they click on save button to persist the Order.
Responding To Comment
This is how I use the domain class from controller:
def save = {
Order order = new Order()
order.addItem(new Item())
order.addItem(new Item())
repository.create(order)
}
The creation of Order and its LineItem is in one transaction. If one of the LineItem can't be created, no Order will be created.
I tend to have method that represent a single transaction, such as:
def deliver = {
Order order = repository.findOrderByNumber('ORDER-1')
order.deliver()
// save order if necessary
}
Anything inside deliver() will be executed as one single transaction. If I need to execute many unrelated methods in a single transaction, I would create a service class.
To avoid lazy loading exception, I use JPA 2.1 named entity graph. For example, in controller for delivery screen, I can create method to load delivery attribute and ignore bonus, such as repository.findOrderByNumberFetchDelivery(). In bonus screen, I call another method that load bonus attribute and ignore delivery, such as repository.findOrderByNumberFetchBonus(). This requires dicipline since I still can't call deliver() inside bonus screen.
I think the root of the problem is in false dichotomy. How is it possible to extract these 2 models: rich and "anemic" and to contrast them to each other? I think it's possible only if you have a wrong ideas about what is a class. I am not sure, but I think I found it in one of Bozhidar Bozhanov videos in Youtube. A class is not a data + methods over this data. It's totally invalid understanding which leads to the division of classes into two categories: data only, so anemic model and data + methods - so rich model (to be more correct there is a 3rd category: methods only even).
The true is that class is a concept in some ontological model, a word, a definition, a term, an idea, it's a DENOTAT. And this understanding eliminates false dichotomy: you can not have ONLY anemic model or ONLY rich model, because it means that your model is not adequate, it's not relevant to the reality: some concepts have data only, some of them have methods only, some of them are mixed. Because we try to describe, in this case, some categories, objects sets, relations, concepts with classes, and as we know, some concepts are processes only (methods), some of them are set of attributes only (data), some of them are relations with attributes (mixed).
I think an adequate application should include all kinds of classes and to avoid to fanatically self-limited to just one model. No matter, how the logic is representing: with code or with interpretable data objects (like Free Monads), anyway: we should have classes (concepts, denotats) representing processes, logic, relations, attributes, features, data, etc. and not to try to avoid some of them or to reduce all of them to the one kind only.
So, we can extract logic to another class and to leave data in the original one, but it has not sense because some concept can include attributes and relations/processes/methods and a separating of them will duplicate the concept under 2 names which can be reduced to patterns: "OBJECT-Attributes" and "OBJECT-Logic". It's fine in procedural and functional languages because of their limitation but it's excessive self-restraint for a language that allows you to describe all kinds of concepts.
Anemic domain models are important for ORM and easy transfer over networks (the life-blood of all comercial applications) but OO is very important for encapsulation and simplifying the 'transactional/handling' parts of your code.
Therefore what is important is being able to identify and convert from one world to the other.
Name Anemic models something like AnemicUser, or UserDAO etc so developers know there is a better class to use, then have an appropriate constructor for the none Anemic class
User(AnemicUser au)
and adapter method to create the anemic class for transporting/persistence
User::ToAnemicUser()
Aim to use the none Anemic User everywhere outside of transport/persistence
The classical approach to DDD doesn't state to avoid Anemic vs Rich Models at all costs. However, MDA can still apply all DDD concepts (bounded contexts, context maps, value objects, etc.) but use Anemic vs Rich models in all cases. There are many cases where using Domain Services to orchestrate complex Domain Use Cases across a set of domain aggregates as being a much better approach than just aggregates being invoked from application layer. The only difference from the classical DDD approach is where does all validations and business rules reside? There’s a new construct know as model validators. Validators ensure the integrity of the full input model prior to any use case or domain workflow takes place. The aggregate root and children entities are anemic but each can have their own model validators invoked as necessary, by it’s root validator. Validators still adhered to SRP, are easy to maintain and are unit testable.
The reason for this shift is we’re now moving more towards an API first vs an UX first approach to Microservices. REST has played a very important part in this. The traditional API approach (because of SOAP) was initially fixated on a command based API vs. HTTP verbs (POST, PUT, PATCH, GET and DELETE). A command based API fits well with the Rich Model object oriented approach and is still very much valid. However, simple CRUD based APIs, although they can fit within a Rich Model, is much better suited with simple anemic models, validators and Domain Services to orchestrate the rest.
I love DDD in all that it has to offer but there comes a time you need stretch it a bit to fit constantly changing and better approach to architecture.
Here is a example that might help:
Anemic
class Box
{
public int Height { get; set; }
public int Width { get; set; }
}
Non-anemic
class Box
{
public int Height { get; private set; }
public int Width { get; private set; }
public Box(int height, int width)
{
if (height <= 0) {
throw new ArgumentOutOfRangeException(nameof(height));
}
if (width <= 0) {
throw new ArgumentOutOfRangeException(nameof(width));
}
Height = height;
Width = width;
}
public int area()
{
return Height * Width;
}
}
Right now, I have a domain entity named StyleBundle. This StyleBundle takes a list of Styles:
public class StyleBundle
{
public StyleBundle(List<Style> styles)
{
this.Styles = styles;
}
public IEnumerable<Style> Styles { get; private set;}
}
So, in my original design, a StyleBundle should never be created with an empty Style list. This was a rule that the domain experts basically said was good.
I wrote this using a guard clause in the constructor:
if (styles.Count() == 0)
throw new Exception("You must have at least one Style in a StyleBundle.");
which made sure I could not create StyleBundle in an invalid state. I thought an exception made sense here b/c a StyleBundle being created without at least one Style was exceptional in the system.
Of course, change came down the road during the rest of the project, and now it should be possible for a user to create a StyleBundle without Styles, but they should not be allowed to PERSIST a StyleBundle without Styles.
So now I'm looking at my guard clause and realizing that I can't have the exception thrown from the constructor anymore.
Moving forward, I have a Service/Application layer that my code-behinds interact with when they're working with StyleBundles. In my Service Layer, I have a StyleBundleService class, and that class exposes basic functionality to the UI... among them is "CreateStyleBundle".
It seems as if I'll have to have my Service Layer check to see if the StyleBundle does or does not have any Styles before it's persisted to the database, but something about this decision feels "wrong" to me.
Anyone run into a similar thing? Basically, the different between the state of an object being valid when "new'ed up" vs. the state of the same object when it comes to persistence?
Thanks!
Mike
I would add an IsValid method to your entity. This would check if the entity is currently in a valid state (in your case, check if there are styles).
This method can be called from your Repository to check if an entity may be persisted. You can add more rules to the IsValid method for specific entities and you can implement something like a collection of Validation errors is you want to throw a meaningful exception.
Expanding what Wouter said, plus handy BeforeSaving and BeforeDeleting methods:
public interface IDomainObject<T>
{
bool IsValid();
}
public interface IEntity<T> : IDomainObject<T>
{
}
public interface IAggregateRoot<T> : IEntity<T>
{
void BeforeSaving();
void BeforeDeleting();
}
public interface IAggregateRoot { //or simply IEntity depending on the model
bool IsValid();
}
public class StyleBundle : IAggregateRoot<T> {
return styles.Count() > 0
}
public class StyleBundleRepository : Repository<StyleBundle> {
}
public abstract class Repository<T> : IRepository<T> where T : class, IAggregateRoot<T> {
public T Save(T t)
{
t.BeforeSaving(); //for all AggregateRoots, maybe logging what the aggregate was like before the changes
if(!t.IsValid())
throw Exeception("Entity invalid");
EntityStore.Current.SaveChanges();
// "AfterSaving" here, i.e.: log how the entity looks after the update
}
}
Edit: I dont personally use the IsValid idea, I go with a full class of EntityValidationErrors where I can report back to the client what was wrong before attempting to save, things that shouldnt be null, shouldnt be empty (like your Styles etc)
There are multiple strategies:
Some developers prefer to create 2 methods in the entity itself, one called IsValid() which validates the entity in terms of business rules (general validation) and another one called IsValidForPersistence() which validates the entity for persistence.
Regarding IsValid() I prefer instead not to allow invalid state in the first place by validating all inputs, and to support invariants I use factory or builder.
you may check the link http://www.codethinked.com/thoughts-on-domain-validation-part-1
for some thoughts.
I know, this question is three years old, but seeing the current answer is something I like to respond to. We are talking about the domain data. Hence, there can't be a valid StyleBundle with 0 objects. I imagine, you have a frontend editor somewhere, were you create a "new" StyleBundle and have to add at least one style, before hitting the "save" button.
At this point in the frontend, you won't have a domain object. You may have a data transfer object, that will be send with a "CreateNewStyleBundle" command.
In my opinion, the domain object must be agnostic to persitance and should always be in a valid state. If you have to call a "IsValid" method, you circumvent the whole idea of having domain objects in the first place.
That's just my humble opinion.
I am developing application having business objects created from EF 4.0. The application is layered with Data Layer having repository of classes. Above that is a business layer where business processes are mapped as per the requirements. Business layer is calling data layer.
Business objects have complex associations. One scenario:
Merchant has Multiple Addresses
Merchant belongs to one Category
Merchant has an Account
Account has a Wallet
User will be creating a new merchant along with above mentioned business objects (graph). There are various business rules when creating and updating a merchant.
I would like to split my validations into two sub sections. 1) Scalar Property Validation to be handled by Validation Blocks 5.0 and 2) Business Process Rules Validation to be handled in business layer components. However, i am facing difficulty on having a centralized way to report broken rules (Scalar Properties validation and Business Process Rule Validation). I don't want to inject exceptions everywhere where business rule in is violated as per the business process mapped.
One e.g is following:
When creating a new merchant, Category needs to be validated. Because if a certain type category is associated with this new merchant then business rule says that such merchant cannot exists twice in the system.
Now, when a UI pass the new merchant graph to business layer component, i first validate BO Scalar properties validation (validated bu Validation Blocks) then this BO is passed into business process rule validation methods to check various rules. There are possible violation points which i want to report and shall not allow the merchant and graph objects to be persisted.
Please share any value able design approach to manage centralized validation rule logging and reporting to UI layer.
EDIT: I don't want to incorporate validations on EF SaveChanges, ChangeAssociation etc event handlers.
While you said you don't want to throw exceptions, I found throwing exceptions very effective. Especially when you having multiple sub systems validating the system, throwing one single type of exception as a facade will be very effective.
What you can do is creating a custom exception (i.e. named ValidationException) that will be thrown either when your Validation Application Block (VAB) reports error or the business rules report errors. In the presentation layer you will have to catch this ValidationException and report this exact type of exception in a user friendly way to the end user.
Using a single exception type for both validation sub systems, allows you to report errors in a consistent way, and also ensures that validation errors won't get unnoticed when you (or an other developer) forgets to handle validation errors. Handling errors should be very explicit IMO. When you let methods return a list of errors it is easy to forget to handle them. When creating a custom exception, it is easy to add a property to that exception type that contains a list of validation errors. Such a list of errors is easily extracted from VAB. I don't know what validation system you use for your business rules validation, but it can't be to hard to extract a list of error codes from it.
The most simple way to handle this in UI is of course by using a try-catch:
var businessCommand = new CreateNewMerchantCommand();
businessCommand.Name = "Wikki";
// etc
try
{
businessCommand.Execute();
}
catch (ValidationException ex)
{
UIValidationHelper.ReportValidationErrors(ex.Errors);
}
Of course having these try-catch statements all over the place is ugly, but at least this code is easy to follow. Dependent on how you structured your business layer and the UI technology you use, there are prettier solutions you could use. For instance, you can wrap the actual operation that can fail with an action as follows:
var businessCommand = new CreateNewMerchantCommand();
businessCommand.Name = "Wikki";
// etc
UIValidationHelper.ExecuteOrDisplayErrors(() =>
{
businessCommand.Execute();
});
The UIValidationHelper would look like this:
public static class UIValidationHelper
{
public static void ExecuteOrDisplayErrors (Action action)
{
try
{
action();
}
catch (ValidationException ex)
{
// Show the errors in your UI technology
ShowErrorMessage(ex.Errors);
}
}
}
An other option, that I've used myself in the past, is by extending the business layer with events. For this to work you need a construct such as commands, as I use in my examples. When using events, the UI could look like this:
var businessCommand = new CreateNewMerchantCommand();
businessCommand.Name = "Wikki";
// etc
businessCommand.ValidationErrorOccurred +=
UIValidationHelper.DisplayValidationErrors;
businessCommand.Execute();
This example hooks a static method to the ValidationErrorOccurred event of a command instance. The trick here is to let the Execute method of that command catch ValidationExceptions and route them to the ValidationErrorOccurred when it is registered. When no method is registered, this exception should bubble up the call stack, because an unhandled validation exception should of course not get unnoticed.
While it is possible to of course do this directly from your business layer, it would make your business layer dependent on a particular validation technology. Besides this, this method allows clients to choose to handle validation errors in any way they want or decide not to handle them at all (for instance when you don’t expect any validation errors to occur in a particular use case).
When using ASP.NET Web Forms, the DisplayValidationErrors method of the UIValidationHelper could look like this:
public static class UIValidationHelper
{
public static void DisplayValidationErrors(
object sender, ValidationErrorEventArgs e)
{
Page page = GetValidPageFromCurrentHttpContext();
var summary = GetValidationSummaryFromPage()
foreach (var result in e.Error.Results)
{
summary.Controls.Add(new CustomValidator
{
ErrorMessage = result.Message,
IsValid = false
});
}
}
private static Page GetValidPageFromCurrentHttpContext()
{
return (Page)HttpContext.Current.CurrentHandler;
}
private ValidationSummary GetValidationSummaryFromPage(Page page)
{
return page.Controls.OfType<ValidationSummary>().First();
}
}
This static helper method injects the messages of the reported errors into a ValidationSummary control on the page. It expects the page to contain a ValidationSummary control at root level of the page. A more flexible solution can easily be created.
The last thing that I like to show you is how the the BusinessCommand would look like when adopting this solution. The base class of these commands could look something like this:
public abstract class BusinessCommand
{
public event EventHandler<ValidationErrorEventArgs>
ValidationErrorOccurred;
public void Execute()
{
try
{
this.ExecuteInternal();
}
catch (ValidationException ex)
{
if (this.ValidationErrorOccurred != null)
{
var e = new ValidationErrorEventArgs(ex);
this.ValidationErrorOccurred(this, e);
}
else
{
// Not rethrowing here would be a bad thing!
throw;
}
}
}
protected abstract void ExecuteInternal();
}
The ValidationErrorEventArgs looks like this:
public class ValidationErrorEventArgs : EventArgs
{
public ValidationErrorEventArgs(ValidationException error)
{
this.Error = error;
}
public ValidationException Error { get; private set; }
}
I hope this all makes sense and sorry for my long answer :-)
Good luck.
Object member validation can be done within encapsulated business objects. Whether you do this in the setter properties or as separate method calls is up to you. Should the objects be set with values that are invalid, should the application allow data into the system that is of the wrong type, range checks etc.
As for the Rules part, I would look at the visitor pattern for each object graph that your trying to achieve some rules checking on. I would report this back probably as a new nested object based on what was found. My personal preference to this reporting side, is to use a visitor pattern that produces an XML Document or some other custom nested class depending on your efficiency needs. The actual rules within the visitor pattern can be declared outside of the visitor pattern, preferably in a declarative approach. For example CheckDuplicateRecord. This would allow for reuse.
Keep all this in the same layer as the Business Layer, but further sub divide the business layer into a Rules validation layer and the Business Objects.
My personal approach with using EF is to use POCO objects as these allow for scalability. I would then do some validation on the UI, then do some validation when transported to the Business Object layer, then do the same again in the EF DAL layer.