BG Development


Страници: (4) [1] 2 3 ... последна »  ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> .NET Core Web API с EFCore, Repository и UoW шаблони, Service Layer
relax4o
Публикувано на: 30-06-2020, 12:20
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2563
Регистриран на: 04.04.07



От няколко дни чета статии, гледам видея и какво ли не, относно дали въобще е нужно да имплементирам Repository Pattern и Unit of Work Pattern при използването на Entity Framework Core. Все пак EF Core имплементира и двете. DbContext е UoW, DbSet са repository-тата.

В този случай, не мога ли просто да използвам тази логика в Service Layer?

Защото, ако имплементирам и Repository Pattern и след това добавя service layer, голяма част от проекта ще стане една голяма фасада от ненужни слоеве.

Говоря за неща от рода на:
CODE

// Service
public User GetUserByName(string name)
{
    return _userRepository.GetUserByName(name);
}

// Repository
public User GetUserByName(string name)
{
    return _context.User.FirstOrDefault(u => u.Name == name);
}


или съм виждал имплементации от този род:
CODE

// Service
public User GetUserByName(string name)
{
    return _userRepository.Find(u => u.Name == name).FirstOrDefault();
}

// Repository
public IQueryable<User> Find(Expression<Func<User, bool>> predicate)
{
    return _context.Where(predicate).AsQueryable();
}


като в случая тука е generic repository. Не съм сигурен кое от двете е по-правилно или и двете са грешни.


Масово нещата, които намирам в интернет са остарели, а неща, които са за .NET Core изглеждат сякаш ги копират един от друг на сляпо.

Има ли смисъл да се имплементира repository pattern, ако се използват само базовите CRUD операции?
На мен ми изглежда като ненужно, защото се добавя още един слой, който е общо взето абстракция върху абстракция.

От всичко прочетено, в главата ми стана една мазаница и не мога напълно да разбера кога мога или дали мога да заменям repository с service-и само или обратно.

В момента трябва да разработя не толкова сложен web api, който най-вече ще се явява като хранилище, но и знам, че ще има и някаква бизнес логика за някои операции. Това добре, знам, че ще ми трябва service layer.

Лоша практика ли е да се миксират след това по контролерите извиквания на Repository-та и сървиси или ако се изгради сървис слой за едно нещо, всички repository-та трябва да минат през сървис слоя (което за мен изглежда ненужно).

За толкова прост API, тези неща ми изглеждат доста ненужни, но опита ми с .NET е малко и не знам в момента какви са добрите практики.

За Unit of Work, едновременно изглежда удобен, в същото време ненужен понеже context-а е същото.



--------------------
Бисери :D

QUOTE (oveRLuckEd)
Ползваш някоя нова версия на PHP, която е вече ооп ориентирана и заради това ти я изкарва тази грешка.


QUOTE (nbacool2)
Щом няма input полета, значи няма откъде да се направи SQL инжекция Very Happy
PM
Top
stewie
Публикувано на: 30-06-2020, 13:07
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 7349
Регистриран на: 14.07.16



Ако операциите ти са прости, може като всеки втори индиец да си сложиш едно generic repository, което ако се наложи за по-сложни операции да го унаследиш. Гадно или не, правилно или не върши работа за малки проекти. Ако имаш по-сложна логика изнасяш я в сървисен слой, който комуникира със съответните репозиторита.

Направи си дженерик контролер, който вика дженерик репозиторитата и mapping за всички CRUD операции. Дори и да дублицираш модели пази си разделен API и DB модел (Не се знае какъв PCL може да ти изискат ако не си само с уеб клиенти).

Гледай да не ръгаш логика в крайните контролери.

Ако искаш да разтеглиш локуми и захарни памуци и да си супер юните тестван (на книга) почваш със CQRS и си правиш generic QueryProcessor и CommandHandler и там понятието репозитори изчезва, а понятието сървис придобива друг смисъл. Втората опция е ако имате пари за харчене и да се намирате на работа.

Това мнение е било редактирано от stewie на 30-06-2020, 13:11
PM
Top
korsarq
Публикувано на: 30-06-2020, 14:48
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 360
Регистриран на: 30.11.16



..........................

Това мнение е било редактирано от korsarq на 30-06-2020, 14:48
PMEmail Poster
Top
JanBirdX
Публикувано на: 30-06-2020, 15:19
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1740
Регистриран на: 21.02.05



QUOTE (stewie @ 30-06-2020, 13:07)
...

И какво ще спечели от това освен да пише код кат ахмак?
PMEmail Poster
Top
stewie
Публикувано на: 30-06-2020, 15:26
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 7349
Регистриран на: 14.07.16



QUOTE (JanBirdX @ 30-06-2020, 16:19)
QUOTE (stewie @ 30-06-2020, 13:07)
...

И какво ще спечели от това освен да пише код кат ахмак?

Ти искаш без да пише код ли ? Я обясни как става да разбера и аз?
PM
Top
JanBirdX
Публикувано на: 30-06-2020, 15:30
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1740
Регистриран на: 21.02.05



Не ми се прави на ощипана госпожица, какво ще му помогнат репозиторитата в случая?
PMEmail Poster
Top
stewie
Публикувано на: 30-06-2020, 15:42
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 7349
Регистриран на: 14.07.16



QUOTE (JanBirdX @ 30-06-2020, 16:30)
Не ми се прави на ощипана госпожица, какво ще му помогнат репозиторитата в случая?

Ти да не си от тея дето викат направо DbContext в контролерите, ощипан господине?
PM
Top
thrawn
Публикувано на: 30-06-2020, 15:43
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2963
Регистриран на: 17.01.17



Става по-удобно за разработка. Можеш да работиш "in-memory" с колекции докато някой се натутка с базата данни.
Въпреки, че е факт, че никой не сменя хранилището и репозиторитата стават просто излишна абстракция то има варианти при които се добавя кеширане и там подобни оптимизации и тогава подходът е удобен. Лично аз гледам винаги да използвам сървиз слой между базата данни и приложението, макар, че не ползвам чисто репозитори щото практически е безсмислено.
PMEmail Poster
Top
JanBirdX
Публикувано на: 30-06-2020, 15:45
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1740
Регистриран на: 21.02.05



Отговори какво ще помогнат репозиторитата, освен да пише код кат ахмак? Някакво хипотетично бъдеще? Разделение за по лесна подръжка?
PMEmail Poster
Top
stewie
Публикувано на: 30-06-2020, 15:52
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 7349
Регистриран на: 14.07.16



Ти ми отговори сега дали ще ми четеш лекция как самият DbSеt е имплементация на repository и колко е грешно generic repository, и как е по-яко да пише като ахмак едни и същи заявки. Интересно и как ако му се наложи да смени persistent storege-a, какво ще прави с набитата db access логика директно в контролерите си.

Това мнение е било редактирано от stewie на 30-06-2020, 15:57
PM
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (4) [1] 2 3 ... последна » Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2019 | BG Development | All Rights Reserved
RSS 2.0