하위 세트 만있는 DB 또는 한 개체로 가득 찬 모든 속성이있는 여러 개체가있는 비즈니스 계층

Question

나는 중간 크기 시스템을 구축하고 있으며, 아마도 당신이 전에 직면 한 문제가있는 문제에 직면하고 있습니다. 내 비즈니스 계층에서는 해당 비즈니스 메서드에 중요한 속성의 하위 집합으로 비즈니스 오브젝트를 반환합니다. 의미없는 이름으로 많은 객체로 끝나거나 주어진 속성의 하위 집합 만 채워집니다. 방법. 내가 예를 들어 보게 해줘.

케이스 1

사용자는 도시에 속합니다. 이는 CANTS가 상태와 국가에 속하며 User, City 및 State 및 Country가 많은 필드가있는 데이터베이스의 테이블이지만 사용자 목록을 원합니다. 주문 목록이므로 중요한 속성 (UserWithOthers)만으로 UserId, UserName, CityName, StateName, CountryName, List<Order>와 같은 Business Object를 작성하고 DAL은 데이터베이스에서 해당 필드 만 검색합니다.

케이스 2

이제 사용자가 주문량을 반환하고 싶습니다. Business Object (UserId, UserName, CityName, StateName, CountryName, OrdersCount)에서 다음 필드로 끝납니다. 예를 들어 UserWithOrderCount 에 대해 클래스를 호출 할 수 있습니다.

몇 가지 옵션을 생각했습니다 :

1. 두 개의 비즈니스 클래스를 각 DAL 메소드에서 개별적으로 채 웁니다 (이 객체는 간단하지만 재사용을 위해 캡슐화되어야하는 복잡한 선택 쿼리를 가질 수 있으므로 저장소 패턴이 잘 맞지 않도록 캡슐화되어야합니다. 나는 그것을 생각한다).
2. 모든 속성 (User)으로 하나의 오브젝트를 생성하고 각 DAL 메소드에서 서브 세트 만 채우지 만 메소드를 사용할 때 의미 론적 커플 링을 의미하지만 메소드의 하위 집합을 알아야하고 시맨틱 커플 링은 모든 커플 링 중 최악입니다.
3. 옵션 1은 나중에 다른보기에서 필요한 경우 잘 처리되지 않습니다. .
4. ASP.NET MVC 선행을 사용하면 ViewModel이 필요하다고 알려줍니다.보기에 전달할 수 있음을 알려줍니다.하지만 Businnes Layer에서 ViewModels를 반환하려는 것으로 생각했지만, 좋은 생각은 생각하지 않습니다. 나는 무언가를 위반하는 것처럼, 비즈니스 계층이 다른 어셈블리에 있고 웹 응용 프로그램이 아닌 다른 어셈블리에 있기 때문에 불가능합니다.
5. 나는 반복해서 동일한 Linq 쿼리를 쓰고 싶지 않지만 nhibernate 또는 efcodeFirst를 사용하는 경우 "Like"옵션이면 작은 비즈니스 객체의 톤을 만들어야합니다.

   어떻게이 상황을 처리합니까? 나는 이것이 높은 수준의 설계 결정이라고 생각한다.

Answer 1

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.