Strato aziendale con più oggetti con tutte le proprietà riempite da db o un oggetto con solo un sottoinsieme pieno

Question

Sto costruendo un sistema di dimensioni medio e sto affrontando un problema che probabilmente alcuni di voi hanno affrontato prima. Nel mio strato aziendale restituisco gli oggetti aziendali con un sottoinsieme di proprietà che sono importanti per quel metodo aziendale, sono preoccupato perché posso finire con molti oggetti con nomi privi di significato o solo uno in cui solo un sottoinsieme di proprietà è riempito in un dato metodo. Lasciami mettere un esempio.

Caso 1

Ad esempio, un utente appartiene a una città, che a loro volta appartiene a uno stato e un paese, User, City, State e Country sono tabelle sul mio database con un sacco di campi, ma voglio un elenco di utenti con Un elenco di ordini, quindi creo un oggetto business richiesto per esempio UserWithOthers con solo le proprietà importanti (UserId, UserName, CityName, StateName, CountryName, List<Order>) e il mio DAL recupera solo i campi dal database.

Caso 2

Voglio restituire ora un utente con la quantità di ordini, termina con i seguenti campi nel mio oggetto Business (UserId, UserName, CityName, StateName, CountryName, OrdersCount) e la classe potrebbe essere chiamata ad esempio UserWithOrderCount

Ho pensato in alcune opzioni:

.
1. Rendi che due classi aziendali e riempili separatamente in ciascun metodo DAL (questi oggetti sono semplici ma considerano che il metodo può avere una query di selezione complessa che deve essere incapsulata per il riutilizzo in modo che il modello del repository non si adatta bene, almeno Penso che).
2. Crea solo un oggetto User con tutte le proprietà (UserId, UserName, CityName, StateName, CountryName, OrdersCount, List<Order>) e riempi solo un sottoinsieme in ciascun metodo DAL, ma ciò implica un accoppiamento semantico quando si utilizza un metodo, poiché è necessario sapere quale sottoinsieme dei campi viene compilato dal database e Accoppiamento semantico è il peggiore di tutti i giunti.
3. L'opzione 1 non mantiene bene se ho bisogno più avanti in un'altra vista, sia, List<Order> e proprietà OrdersCount.
4. Considera ora che se usi ASP.NET MVC BUONA PRACHE Pratiche indica di aver bisogno di un ViewModel da passare alla vista, ho pensato di restituire i viewmodels dal mio strato di Businnes, ma non penso sia una buona idea, si sente Come sto violando qualcosa, e anche non è possibile perché il mio livello aziendale è in un altro assemblaggio e non sull'applicazione Web.
5. Non voglio scrivere la stessa query linq più e più volte, ma se usi nibernate o efcodefirst è opzione "come" "come", e dovrò creare tonnellate di piccoli oggetti d'affari.

   Come gestisci questa situazione? Penso che questa sia una decisione di progettazione di alto livello.

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.