Hello there,

I am having a query regarding my N-layer ASP.Net application.
Suppose, I am having following projects -

- PTS.Web (Web Application)
- PTS.BLL (Business Layer Class Library)
- PTS.DAL (Data Access Class Library)

Now, as I will need ENTITY object to move data between the layers.
Where do you suggest should I create the class for my entity objects?

Should I put them in PTS.Bll or
should I create an extra class library with the name say, PTS.Common (with reference of PTS.Common added to all other projects)? 

Could you please provide any idea backed up by some good reason.

Thanks in advance!

This is how I do things, today, but have followed this model in various forms for about 8 years now. Currently I use Entity Framework for my DAL. Before I used the Data Access Application Blocks in the Enterprise Library.

When you generate an enity model it creates the entities for you, with relationships, a custom data context, etc. The generated code is more or less a base for your business layer.

I then extend the entity classes generated by the model, they are all partial classes so you are good to go! I also create a repository class. This class holds methods to CRUD the data using the model's entities and datacontext.

The web layer then works with the entities and the repository(ies) to retrieve my business objects (entities).

I hope this helps you out.

Hello Chris,

Thanks for your comments.
I will definitely give a hands-on to Entity Framework.

Any other ideas out there? 

I added another layer when I came up against this problem - which contained all the classes which were dependent on nothing whatsoever.  That means splitting your business / service layer in two. I can't see a reason for not doing that.

PS: If I were creating a new asp.net application I would actually use the MVC with Fluent nHibernate, or, perhaps, some other ORM.

Strictly speaking it was actually another project - so you could say I split the business layer into two projects.

When you mean a entity, I understand it's going to be POCO classes - just properties, fields and no methods/business logic. The assumption is that your BLL will contain only methods to handle/manipulate the entities and no state. If so, I will go ahead creating a new project for Entities which will be used by all other layers - they just act as data containers.

If your BLL has state + behaviour, then DTO implementation is suggested.

Saravanan

I follow Separate BusinessEntities folder/project where I place the entity classes.

These enities can be called on your UI {code behind} BLL and even in DAL

It would be better to make a new one Which can be called BO {business objects} or BE {business entities}.

[If this desgn have any flow then please comment on it]