Business Entity == DTO?

I have this confusion.  The Business Entity that we are using to hold data and pass around the layers (UI, Business and DALC), are they equal to DTO? 

I've always had this impression they are; but according to Martin Fowler, a DTO is used to aggregate data for passing across network/process boundaries (e.g. sent across the wire via Web Services). 

So is Business Entity == DTO?

In my opinion again, Business Entity != DTO. Take a look at this microsoft site http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bpsdk/BPIG_Ch08_EntityOverview1048369.asp

One of the key point of the DTO is that it should not contain business logic and if there is behavior, should be limited only to internal checking and basic validation for the aggregated data it holds. Business Entity on the other hand, is composed of the following pieces: The entity, the entity virtual collection and the entity service. These 3 pieces even though can exist independently do carrying a closed relationship with each other.    

 

While this is a fairly old thread, I wanted to comment on this question because I ran across it looking for discussions on the relation of Business Entities and DTOs.

 First, the link provided describing the parts of a business entity as "entity, entity virtual collection, and entity service" is within the context of a product called the "Business Portal SDK".  While I am not familiar with this product, the term as used here seems more peculiar to this product and does not seem to correspond to Business Entities as defined by Microsoft's Application Architecture for .NET: Designing Applications and Services.  In this document a Business Entity is defined as follows: 

Business entity components: Most applications require data to be passed between components. For example, in the retail application a list of products must be passed from the data access logic components to the user interface components so that the product list can be displayed to the users. The data is used to represent real-world business entities, such as products or orders. The business entities that are used internally in the application are usually data structures, such as DataSets, DataReaders, or Extensible Markup Language (XML) streams, but they can also be implemented using custom object-oriented classes that represent the real-world entities your application has to work with, such as a product or an order.

 The document goes on to say that Business Entities "should not initiate any kind of transactions, and should not use data access APIs—they are just a representation of data, potentially with behavior."

Another good source on Business Entities is Designing Data Tier Components and Passing Data Through Tiers.  This document discusses the following ways of implementing Business Entities: 

• XML
• Generic DataSet
• Typed DataSet
• Custom business entity components
• Custom business entity components with CRUD behaviors

The conclusion I've come to after attempting to synthesize the available information is this:

 A Business Entity is simply an object that models a real world entity.  This may or may not contain behavior, but the contained behavior is generally limited to simple methods which act upon the contained data and do not interface with APIs or other components outside of itself.  My personal opinion is that once a business entity starts performing CRUD operations or other behaviors outside of its own data, it ceases to be a Business Entity and becomes a Business Object/Domain Object.  Of course, these are more Java centric pattern designations, so I should probably call it a blending of a Business Entity and a Business Component or Business Workflow to stick with Microsoft terminology.  The concept of a Business Entity doesn't seem to be strongly formed or used outside of the .Net community and the terminology of Domain Objects, while usurped by the .Net community, doesn't seem to be used by any of the Microsoft documents I've read.

 To address the original question, there is a difference in the purposes behind Data Transfer Objects (which were conceived to deal with issues involving EJB development) and Business Entities, but in practice they may end up looking exactly the same depending on where you fall on the spectrum of using business entities to only model data vs. data + behavior.

 

Derek 

 

IMHO, DTO represents your database model (normally database tables' field).

So if you have a table Customer which columns like CustId, Full Name and Country, your DTO you will have a class Customer with 3 fields too.

Correct me if I am wrong :)

I only make use of a simple perception to this topic.

DTO = Data Transfer Object. As the name suggests, it is transmitted/communicated outside of application boundaries (queue, web service, etc), where another application taking the raw schema and data will then convert into their own

BE = entities that live within the application and possessing the necessary business/application logic that does not represent too big a rule or workflow. (validation, integrity, etc)

If you're using OR/Ms like NHibernate, ActiveRecord, Linq, WORM etc..., your basic "Model" object which ties directly with your database should be used exclusively within your application domain.

 Now in cases whereby you need to "transfer" data out of the application, from say a WCF service, you will need to ensure only "data that is needed to be transferred" are actually passed out of your application. This not only reduces unnecessary code / data transfer, as well as improving security.

 Here's a method of implementation that I did.

[DataContract] public class PersonDTO
{

     private string name;

[DataMember] public string Name
{ get{ return name; } set { name = value;} }

     
     public PersonDTO( Person personModel )
     {
         this.name = personModel.Name;

     }
} 

and our Person class can have other fields like Id, Date of birth etc, all of which are not required.

A simple call can be:

[ServiceContract] public interface IMyServiceContract{ 

 [OperationContract] PersonDTO GetMyPerson( Guid id ); 

 }

and your Service Host can be

public class MyService : IMyServiceContract {

public PersonDTO GetMyPerson( Guid id )

{
    Person person = PersonController.GetPerson( id );

    if ( person != null ) return new PersonDTO ( person );

    return null;

}

} 

DTO is just like a glorified C struct, all data. business entity should not just have data but business rules and behaviour.