Witam,
Stworzyłem sobie proste API przy użyciu ASP.NET Core.
Jednak zmieniłem trochę koncepcję projektu. Chciałbym udostępniać tylko część modelu mojej domeny na zewnątrz. A rzeszę chciałbym przetwarzać wewnątrz aplikacji. W takim razie skoro mam już gotowe API, które chcę udostępnić to czy mogę w tym samy projekcie dopisać sobie dalszą część funkcjonalności np w architekturze MVC ?
Moim celem jest aplikacja webowa dla użytkowników, która na zewnątrz udostępnia część danych.
Mozesz miec osobne modele domenowe i transferowe (dto, do uzycia dla api), co ma duzo sensu, bo np wersjonowanie modeli etc
Do mapowania uzyj AutoMappera, ale niech cie reka boska broni od uzywania auto mapowania, tworz profile class Profile
Gdy bedziesz juz mial takie rozdzielenie to mozesz sobie inne funkcje dopisac nawet przez websockety .
Już stworzyłem osobne modele, zrobiłem też profilowanie w osobnej klasie.
Czyli jeśli dopisze sobie widoki i model widoku i kontrolery do projektu to nie będzie to błąd projektowy / koncepcyjny? Docelowo miało być samo API. Nie wiem czy nie na siłę szukam sobie problemu.
Co do widoków to razor jeszcze jest używany?
Jak lubisz archeologie, komercyjnie react jest uzywany, w polaczeniu z swaggerem i autorestem mozna latwo zrobic api
Jak narobisz dodatkowych narosli nad dto tj jakies vm co beda po to zeby byly, to jest blad, ogolnie program powinien byc najprostszy jak sie da, ale nie prostszy
"Trzeba upraszczać, jak można, ale nie bardziej" ~Albert
Pixello napisał(a):
Do mapowania uzyj AutoMappera, ale niech cie reka boska broni od uzywania auto mapowania, tworz profile
class Profile
Osobiście nie poleciłbym automappera nikomu, chyba że aplikacja jest malutka i mapowania banalnie proste. Przy złożonych konwersjach koszt utrzymania jest dużo wyższy niż mapowania implementowanego ręcznie.
@var: mam tylko 10 klas, a mapowane są tylko 3.
Wracam po przerwie :) Jako że chcę mieć docelowo aplikację webową MVC z publicznym API.
Mam jeszcze kilka pytań:
Solution:
API Project
MVC Project
Jak to podejście ma się do istniejącego modelu i połączenia z DB? W zasadzie model i baza danych musi być ta sama.
Przede wszystkim to API jak i MVC (w sensie widoki) możesz mieć w jednym projekcie, tzn. w jednej aplikacji webowej. Dostęp do poszczególnych kontrolerów i akcji możesz kontrolować za pomocą Identity. Natomiast jeśli zależy Ci na "fizycznym" ograniczeniu dostępu do API i np. zezwoleniu tylko dla konkretnych adresów IP lub sieci wewnętrznej to faktycznie wydzielenie oddzielnej aplikacji webowej (API) ma sens. Natomiast wtedy kwestia kontroli dostępu do tego API nie będzie po stronie samego kodu aplikacji a infrastruktury/hostingu. Nie będzie miało znaczenia jak to masz rozdzielone. Po prostu dostęp będzie kontrolowany zewnętrznie.
Co do samego podziału to ma on oczywiście sens. Wtedy taki projekt API jest oddzielną aplikacją która może być hostowana niezależnie od aplikacji MVC. Jeśli zaś chodzi o dostęp do bazy danych i logiki biznesowej to wydziel do tego oddzielne projekty (warstwy). Wtedy twoje projekty API i MVC będą miały dostęp do tych wspólnych modułów. Ogólnie to traktuj projekty webowe jako lekkie warstwy ponad warstwami dostępu do danych i logiki biznesowej. Powinny posiadać jedynie niezbędne minimum takie jak zabezpieczenia i ewentualnie jakieś mapowanie (np. z modeli domenowych do DTO/modeli widoków). Poczytaj o architekturze wielowarstwowej.
Jeśli chodzi ogólnie o podstawy projektowania aplikacji webowych, podziału warstwowego itp. to gorąco polecam darmową, dosyć lekką i krótką książkę od Microsoftu Architecting modern web applications with ASP.NET Core and Azure. Nie zraź się Azure w tytule bo spokojnie można to ominąć- książka i tak wiele objaśnia poza Azure. Jeśli angielski to dla Ciebie problem to online jest wersja po polsku.
@Aventus
Dzięki o to chodziło :)