I have seen countless discussions on this forum where the [Confusion] of designing Business Entities aka Custom Business Entities aka DTO lingers on. Even right now there are many question posted pertaining the same subject. Designing simple Custom Entities is stright forward but the UI needs are very peculiar. If Entity-A holds a link to Entity-B it works fine for a simple screen; however, the problem arises when the UI needs to display Entity-B including [Name] of Entity-A. Since Entity-B only holds a link (without other details) to Entity-A, the user is either forced to include the [Name] of Entity-A in Entity-B as a property or has to define an entirely new Entity-C which is a merger of the Entity-A and Entity-B.

IMO, Custom Business Entities should be [Logically] classified into two [Layers]. One layer should represent the [Core] Business Entities (business domain) while the other represents [Need-Based] Entities. The need-based entities should conform to UI or other needs (such as reporting). For example, the following Custom Entities represent the main business domain:

Customer (CustID, CustName, ...), Order (OrdID, Date, ...) , Product (ProID, ProName, Price, ...) ----- [Core] Business Entities

But the UI may need to display Which Customer bought Which Product (without order details). For such a need, we can have the following need-based entity:

CustomerProductPurchase (CustID, ProID, CustName, ProName, Price, ...)

This is just my opinion. I see the pros and cons of this architecutre BUT would like to hear from the experts...

Thanks..

Hi,

When the UI needs to display related data, you can use the concepts of association/aggregation etc to display "bound" domain objects. This is why for larger projects the domain model can get quite complex and convoluted.

Though it depends on project-to-project basis, I usually use a "lighter" domain model and a "SOA like"architecture (which actually goes quite opposite when compared against a traditional domain driven approach). When it comes to reporting, some times I avoid domain objects completely (in heavy reporting scenarios) and leverage datasets etc.

kashifdotnet:

But the UI may need to display Which Customer bought Which Product (without order details). For such a need, we can have the following need-based entity:

For this case, I would have created a method like: Customer::FindProductPurchaseHistory() which would return a strongly typed collection of Product DTOs or something similar on this line.

HTH,

Vivek

kashifdotnet:

IMO, Custom Business Entities should be [Logically] classified into two [Layers]. One layer should represent the [Core] Business Entities (business domain) while the other represents [Need-Based] Entities. The need-based entities should conform to UI or other needs (such as reporting). For example, the following Custom Entities represent the main business domain:

 

For complex applications I create a Domain Model (containing business entities, value object etc) and a separate set of presentation DTO (Data Transfer Objects – no logic) which is usually a flatter representation of an object graph used exclusively for displaying data. I find this works very well and keeps a nice separation of concerns.

In my opinion, what you call as "need based entities" are nothing but DTOs.

While the business entities model the domain using proper associations and relationships, DTOs are designed to interact with other layers like UI, DAL, service client etc.. based on the needs.

DTOs may be overkill if they resemble similar to business entities...

Vivek:

When the UI needs to display related data, you can use the concepts of association/aggregation etc to display "bound" domain objects

Could you elaborate on "bound" domain objects.

Vivek:

I usually use a "lighter" domain model and a "SOA like"architecture

What would be a light domain model (Entities with properties only)? What i understand from SOA like architecture is that for an entity Customer, you have a service which returns all his Orders. Did i get it right?

Scott:

For complex applications I create a Domain Model (containing business entities, value object etc) and a separate set of presentation DTO

So are you supporting my idea of seperating out light-weight DTOs for specific needs (UI/Reporting)? Scott, for child/parent objects, which of the following do you support:

1. Have a parent FK property in the child?
2. Have a full blown parent object?
3. Have a Service/Method which returns the parent?

saravanan.balasubramanian:

While the business entities model the domain using proper associations and relationships, DTOs are designed to interact with other layers like UI, DAL, service client etc.. based on the needs

 

Are you differentiating between business entities and DTOs. The only difference I see between the two is the details within the Busniess Entity? This also implies that only the DTOs are transfered between all layers. What would be the role of Business Entities in such a case just lieing around?

Thanks for replying...

 

kashifdotnet:

So are you supporting my idea of seperating out light-weight DTOs for specific needs (UI/Reporting)? Scott, for child/parent objects, which of the following do you support:

1. Have a parent FK property in the child?
2. Have a full blown parent object?
3. Have a Service/Method which returns the parent?

 

It depends on what you want to show on your UI/Report, if you need to have a  UI that lists products purchased on a certain day I may just return a simple object like:

    public class ProductsPurchasedTodayDTO
    {
        public string ProductName { get; set; }
        public string CustomerName { get; set; }
        public long OrderId { get; set; }
    }

kashifdotnet:

saravanan.balasubramanian:

While the business entities model the domain using proper associations and relationships, DTOs are designed to interact with other layers like UI, DAL, service client etc.. based on the needs

 

Are you differentiating between business entities and DTOs. The only difference I see between the two is the details within the Busniess Entity? This also implies that only the DTOs are transfered between all layers. What would be the role of Business Entities in such a case just lieing around?

Business entities contain all of the rich logic etc, your DTO are just dumb data transfer objects, the need to be dumb as they may be send of the wire and will need to be serialized so they can't contain methods, check out the code below it may make more sense:

public class OrderService
    {
        public void CreateOrder(OrderDTO order)
        {
            // Convert OrderDTO (used for transport - no logic because it may need 
            // to be serilaised) to full entity which contians business logic
            Order orderEntity = ConvertToOrderFrom(OrderDTO);

            // Use the entity for business logic...
            if (orderEntity.GetBrokenBusinessRules().Count == 0)
            {
                if (orderEntity.CanFulfillStockRequirements())
                {
                    orderEntity.Place();
                }
                else
                {
                    //......
                }
            }
            else
	        {
                //.....
	        }                
                
        }
    }

 

I hope that makes some sense.
Cheers
Scott

 

If you want to make your life simpler you can assign values to DTO-s using AutoMapper. I am using this little utility in some of my projects and it works very well. If you want find out more about AutoMapper then read my blog entry Creating DTOs using AutoMapper.

kashifdotnet:

What would be a light domain model (Entities with properties only)? What i understand from SOA like architecture is that for an entity Customer, you have a service which returns all his Orders. Did i get it right?

Yes, by lighter it means that you dont have complex object-object mappings in your domain model. For example, you dont need nested associations, or "stronger" aggregations in your domain model. Make it more "procedural" and SOA like, keeping things simple.

 

scott@elbandit.co.uk:

public void CreateOrder(OrderDTO order)   

        {   

            // Convert OrderDTO (used for transport - no logic because it may need    

            // to be serilaised) to full entity which contians business logic   

            Order orderEntity = ConvertToOrderFrom(OrderDTO); 

            ...................................  

aha, this does make sence. The idea is to use plain DTOs for data transfer while Busines Objects perform the complex business logic. Using your idea, I can now logically classify the Custom Entities a bit differently i.e instead of having Core Buiness Objects and Need-Based objects, lets have Smart Business Objects and plain DTOs. The smart Business Objects reflect the business-domain and plain DTOs used for UI/Reporting/Data tranfer based on our requirements. The plain DTOs get populated through the Business Objects.

Thanks for the smart idea  Let me look into it further and will jump right back...

 

 

vivek_iit:

For example, you dont need nested associations, or "stronger" aggregations in your domain model. Make it more "procedural" and SOA like, keeping things simple.

So the idea is that instead of having association, we can have a service. For exmaple, lets say we have a Customer object. Instead of the following:

public class Customer
{
        ......
        IList <Order> OrderCollection;
}

the following dependency is preferred:

Customer.GetCustomerOrders (); // a service

Did i get it right???

Thanks for insight

kashifdotnet:

Customer.GetCustomerOrders (); // a service

Did i get it right???

Yes, correct.