business layer with multiple objects with all properties filled from DB or one object with only a subset filled

I am building a middle size system and I am facing a problem that probably some of you have faced before. In my business layer I return business objects with a subset of properties that are important for that business method, I am worried because I can end up with to much objects with meaningless names or only one where only a subset of properties are filled in a given method. Let me put an example.

Case 1

For example, a user belongs to a city, which in turns belongs to a state and a country, User, City, State and Country are tables on my database with a lot of fields, but I want a list of users with a list of Orders, so I create a business object called for example UserWithOthers with only the important properties (UserId, UserName, CityName, StateName, CountryName, List<Order>) and my DAL retrieves only that fields from Database.

Case 2

I want to return now a user with the amount of orders, I end with the following fields in my business object (UserId, UserName, CityName, StateName, CountryName, OrdersCount) and the class could be called for example UserWithOrderCount

I have thought in some options:

1. Make that two business classes and fill them separately in each DAL method (this objects are simple but consider that method can have a complex select query that needs to be encapsulated for reuse so repository pattern doesn't fit well here, at least I think that).
2. Create only one object User with all the properties (UserId, UserName, CityName, StateName, CountryName, OrdersCount, List<Order>) and fill only a subset in each DAL method, but that implies Semantic Coupling when you use a method, because you must know which subset of fields are filled from database, and semantic coupling is the worst of all coupling.
3. Option 1 doesn't handle well if I need later in another view, both, List<Order> and OrdersCount开发者_高级运维 properties.
4. Consider now that if you use ASP.NET MVC good practices tells that you need a ViewModel to pass to the view, I thought to return ViewModels from my Businnes Layer, but I don't think is a good idea, it feels like I am violating something, and also is not possible because my business layer is in another assembly and not the web application.
5. I don't want to write the same Linq query over and over again, but if use NHibernate or EFCodeFirst is "like" option one, and I will need to create tons of small business objects.

How do you handle this situation? I think this is a high level design decision.

First of all, I definitely agree with you about some things not do:

1. Don't partially-populate business objects, as you then put responsibility for knowing which properties are populated onto the business layer's clients, which is very bad practice.

2. Don't return ViewModels from your business layer; your business layer is supposed to represent the business concepts of your application's domain, and a ViewModel is a data object which contains the data necessary to display a particular view of one part of that domain - the two are very different things and the business layer should be completely unaware that its business objects are used in any kind of GUI.

I would go with your first suggestion - create one separate business object to represent each business concept. I would then use an ORM (like EF or NHibernate) to populate those objects for me, with dedicated Repositories for each group of objects. I'd then use an application layer which calls the repositories to return whatever objects are required. to this end your Repository can include methods which return joined Users and Orders for times when you know you need to have those two types used together. This allows you to return a User with all their Orders in one query, while retaining separate, meaningful entities to represent Users and Orders.