EntityFramework generowanie obiektów z domyślnym prefixem

Cześć,
Jest jakaś możliwość żeby przy generowaniu obiektów z DB first, można było do wygenerowanych klas dodać jakiś prefix? np. ""DB_"? standardowy scaffold tego NIE MA, słyszałem, że ma taka funkcję EF Core PowerTools, ale też jej tam nie znalazłem.

Ja nie wiem ale prawie na pewno tego nie potrzebujesz.

Mając w bazie danych tabelki user, role, scaffold wygeneruje klasy User, Role, natomiast ja chciałbym żeby jeszcze przed nimi znalazło się np. DB_ lub POCO_
DB_User, DB_Role. Ręcznie mi się nie chce zmieniać nazw dla X klas po generacji.

Da się pewnie zrobić coś podobnego jak tu: https://stackoverflow.com/questions/46497733/using-singular-table-names-with-ef-core-2

Pytanie: po co? Taki prefix wyglądać będzie baaaardzo brzydko :/

Myślałem żeby w ten sposób oddzielić POCO od obiektów biznesowych, wygenerowałem obiekty za pomocą EF powertools, same czyste properties bez navigation proprties i teraz zastanawiam się co dalej i jak to dalej ogarnąć, bo potrzebowałbym zapewne jakieś obiekty biznesowe, które będą miały większą logikę i powiązania, ale też DTO. I musiałbym ogarnąć mapowania teraz miedzy tymi trzema typami. Aczkolwiek może bym zrobił po prostu dziedziczenie BO : DB, wtedy przed zapisem może w repositoriach starczyło zrobić tylko rzutowanie?

Hmm, chyba coś źle do tego podchodzisz. Wrzuć jakiś większy kawałek kodu i napisz, co chcesz osiągnąć. Wygląda na problem XY :)

blane napisał(a):

Myślałem żeby w ten sposób oddzielić POCO od obiektów biznesowych

No to wystarczy trzymać je w innych projektach.

, wygenerowałem obiekty za pomocą EF powertools, same czyste properties bez navigation proprties

Czemu?

i teraz zastanawiam się co dalej i jak to dalej ogarnąć, bo potrzebowałbym zapewne jakieś obiekty biznesowe, które będą miały większą logikę i powiązania, ale też DTO. I musiałbym ogarnąć mapowania teraz miedzy tymi trzema typami. Aczkolwiek może bym zrobił po prostu dziedziczenie BO : DB, wtedy przed zapisem może w repositoriach starczyło zrobić tylko rzutowanie?

Jeśli chodzi o to, że chcesz oddzielić warstwę składowania od warstwy obiektów biznesowych, to tak, musisz to jakoś mapować. Ale prefiksy w tym nie pomogą.

Czemu?

Żeby oddzielić część DB od reszty,
Tak wiem, że prefixy mi w tym nie pomogą, ale mam przypadki że nazwy tabel są takie jak nazwy klas .net przez co muszę później dokładać przed nazwą klasy namespace. No ale już trudno rozumiem że jest to średni pomysł.
A co myślisz o pomyśle żeby obiekty biznesowy dziedziczyły po tych DB, wtedy mapowanie nie będzie mi potrzebne, a za pomocą automappera może uda mi się ogarnąć mapowanie na DTO.

@blane

A co myślisz o pomyśle żeby obiekty biznesowy dziedziczyły po tych DB, wtedy mapowanie nie będzie mi potrzebne, a za pomocą automappera może uda mi się ogarnąć mapowanie na DTO.

ale why??

Ale co Why?

czemu model biznesowy, zawierający jakąś logikę biznesową

ma dziedziczyć z modelu bazodanowego, często anemicznego?

bo imo ułatwienie sobie mapowania to niezbyt mocny argument

A po co mam trzymać te same propertisy w 2 klasach? Chciałem zrobić tak, że mam klasę DB np. DbKsiążka (tylko pola odzwierciedlające kolumny w tabeli) oraz drugą klasę BoKsiążka, która będzie zwracana z repository, ale ma mieć te parametry, które ma DbKsiążka, żeby mieć informacje o tym co jest w DB, a dodatkowo navigation propertisy które załaduję jeśli będą potrzebne lub np. dodatkowe listy do uzupełnienia w repository np. lista bibliotek w których książka jest dostępna (info z innej tabelki).
Taki miałem plan / pomysł nie wiem czy dobry czy zły, ale nie mam innego stąd tu moja obecność, chciałbym się dowiedzieć zanim zaczne robić jak ewentualnie można to zrobić innaczej?

@blane:

A po co mam trzymać te same propertisy w 2 klasach?

a co zaczniesz robić gdy w modelu bazodanowym zaczną dochodzić ci jakieś techniczne rzeczy np. kolumny przechowujące jakąś wartość w celu uniknięcia przeliczenia itp.

wtedy zaczną ci przenikać do modelu biznesowego

dodatkowo model bazodanowy często jest bardzo prosty, a model biznesowy raczej nie

i nagle takie dziedziczenie "osłabia" ten model biznesowy

To możesz podpowiedzieć jak powinienem to zrealizować? podać jakiś przykład dla wyjaśnienia? żebym zrozumiał o co chodzi.
Mam w modelu biznesowym utworzyć dokładnie takie same pola jak w bazodanowym, ale tych dwóch klas nijak nie łączyć?

To jeszcze trochę rozwinę

Jeżeli masz bardzo prostą domene do zamodelowania, brak większej (lub jakiejkolwiek) logiki, to faktycznie pewnie nic złego by się nie stało gdyby to był nawet 1 model na bazę i domenę (tzw. encja na twarz i pchasz) [0], ale jeżeli planujesz to rozwijać długo, to może jednak nie warto

Mam w modelu biznesowym utworzyć dokładnie takie same pola jak w bazodanowym, ale tych dwóch klas nijak nie łączyć?

np. przemapować, zbudować (builder/factory/etc/etc pattern)

Oczywiście możesz uznać że to jest zbędne i tylko dodaje nadmiarowe klasy oraz kod i możesz mieć rację, bo zależy od sytuacji.

[0]

blane napisał(a):

A co myślisz o pomyśle żeby obiekty biznesowy dziedziczyły po tych DB, wtedy mapowanie nie będzie mi potrzebne, a za pomocą automappera może uda mi się ogarnąć mapowanie na DTO.

Mapowanie nadal będzie potrzebne, bo mapuje się przecież obiekty, a nie klasy.

Jakie DTO masz na myśli?

blane napisał(a):

A po co mam trzymać te same propertisy w 2 klasach? Chciałem zrobić tak, że mam klasę DB np. DbKsiążka (tylko pola odzwierciedlające kolumny w tabeli) oraz drugą klasę BoKsiążka, która będzie zwracana z repository, ale ma mieć te parametry, które ma DbKsiążka, żeby mieć informacje o tym co jest w DB, a dodatkowo navigation propertisy które załaduję jeśli będą potrzebne lub np. dodatkowe listy do uzupełnienia w repository np. lista bibliotek w których książka jest dostępna (info z innej tabelki).

navigation property to terminologia z ORMów, a logika biznesowa nie powinna nic o ORMie wiedzieć. Nie ma też raczej powodu, aby klasy mapowane do tabel pozbawiać navigation properties, czemu chcesz to robić?

blane napisał(a):

Mam w modelu biznesowym utworzyć dokładnie takie same pola jak w bazodanowym, ale tych dwóch klas nijak nie łączyć?

No tak na logikę, to przecież jak je połączysz, to ich nie oddzielisz.

Nie wiem co to za aplikacja musiałaby być, żebym odważył się utrzymywać osobny model persystencji oraz dziedzinowy. Obecnie każdy nowy ORM taki jak EF Core czy NHibernate potrafi dobrze separować model dziedzinowy od fizycznego data store poprzez

• Użycie prywatnych pól zamiast publicznych właściwości z get i set
• Fluent configuration, czyli klasy opisujące mapowanie encji biznesowych na tabele w bazie danych jako alternatywa dla atrybutów typu Table("Users") [Key], itd
• Shadow properties - brak właściwości typu public int RoleId będących kluczem obcym zaśmiecającym model dziedziny informacjami związanymi z bazą danych
• Możliwość zmiany silnika bazy danych na poziomie konfiguracji ORMa (pomijam zmianę z RDBMS na NoSQL bo to jest zmiana w sposobie myślenia o tym w jaki sposób aplikacja operuje na danych i nie związana wyłącznie z warstwą persystencji, przez co taka zmiana rozciąga się na całą aplikację)

Co do navigation properties to są one konieczne i nie ma ich po co ukrywać, ponieważ tworzą graf obiektów tzw agregat w terminologii DDD i pobierając agregat, pobieramy wszystkie zależności które są istotne z punktu widzenia logiki agregatu. Czyli jeżeli chcę wyliczyć wartość zamówienia to pobieram agregat Order razem z OrderItems (Eager Loading) które zawierają informację nt pozycji zamówienia takie jak cena i ilość.