Absence of DTO vs usage of business objects in repository pattern

I am working on a project. The goal is to develop an MVC app along with an API that will be serving live data to lot of interested parties around the World. MVC app will be simple and will allow users to register for usage of Web API. Web API is the real thing, it would be an interface for the rest of the World for massive amounts of valuable data that we have. Some examples of the methods I am going to expose are:

1. List GetAssetsByNation (string NationCode, Datetime StartRange, Datetime EndRange )


2. Bool VerifyAssetDetails (string username, string pwd )


3. Asset GetAssetDetails ( int AssetId )

There are several designs I am thinking of for web api:

Design 1

DAL: Normal data access methods, caching

Domain Layer: Repository methods implementation, Repository interface, Business (domain) objects/entities

BLL: Business methods (logic & validation)

Presentation: MVC app

Design 2

DAL: Normal data access methods, caching, Repository methods implementation

BLL: Repository interface, Business methods (logic & validation), Business objects/entities

Presentation: MVC app

Which approach do you guys think is better? Would you make any changes to above?

• I am using the repository pattern because we intend to change our database system from sql to no-sql one in few years. In order to make the switch as painless as possible, repository pattern is being used.


• I am not using DTO’s here. I cant see any use of them since I think I can pass around Business objects from one layer to another. Is there any con to it given the nature of methods mentioned above.

I am not very good with design patterns, so your opinion of the two above designs would be really appreciated. Thank you very much!