Софтуерно Инженерство
Loading...
+ Нов въпрос
d0m1na7or avatar d0m1na7or 1 Точки

Какво се препоръчва в този случай? [EF + RepoPattern + Uow + projects]

Здравейте на всички. Имам една дилема, но нека обесня точно каква е ситуацията.

1. Имам проект с модели (таблиците в базата ми от данни)

2. Имам др. проект който е за контекстите + repositorry класовете интерфейсите и unit of work- класа.

3. Имам Web Forms проект.

Работя с unit of work контекста до тук всичко е наред.

Обаче се стига до там че в логиката на формите ми изниква нужда от методи който няма как да ги имплементирам в repository класовете а и няма смисъл за да не чупя принципите на данните ми. Имам нужда от написване на класове които ще са такива че те да знаят за Models + Data проектите и там ще имам такива методи които ще ми обединяват големи методи с някакви калкулации и такива методи които няма защо да стоят в Data проекта ми и винаги ще връщам пак някакви данни от базата. Един вид грубо казано в тези новите методи ще имам нещо което не мога по директен начин да взема от др.те слоеве на проекта.

Въпроса ми е... в web проекта да си направя папка с такива класове които примерно ще обединяват много такива методи които не трябва да седят в Data проекта. Това добре ли е? или това нещо се прави пак в Data проекта или в съвсем др. отделен проект само за такива неща?

С нетърпение очаквам съветите Ви. Благодаря предварително.

Успех на всички в начинанията ви.

Anonymous:
Заключена по молба на автора.
RoYaL avatar RoYaL SoftUni Team Trainer 6883 Точки

Щом проектите са различни е време да решиш дали тези проекти, когато ползват зависимостите по между си, ще са на един сървър или не в продъшън среда. Ако ще са на отделни, ще трябва да направиш нещо като Web service за комуникация по между им. Всъщност, и в двата случая най-доброто решение е да си направиш API за комуникация. В единия случай то ще бъде по уеба, а в другия по файловата система.

 

P.S.: А и по всичко личи, че проектите си плачат за пренаписване, така че ако имаш възможност просто ги пренапиши и разкарай Web forms-a като идея въобще :) Това за мен е нещо, което трябва да остане в миналото.

3
d0m1na7or avatar d0m1na7or 1 Точки

Може би аз не се изразих много правилно затова ще го систематизирам.

Class library xxx.Models

- класове описващи таблиците в базата ми от данни.

- папка с mappings където се описва всеки клас с EntityTypeConfiguration за информация на Entity Framework да знае коя таблица какви настройки има (кое е ключ, минимална, максимална дължина и др.)

 

Class librarz xxx.Data

- папка с DbContext там се намира интерфейса и класа на entity framework контекста т.е. кои класове да влизат в базата от данни (има връзка с mappings + models)

- папка с migrations

- папка с Repositories - тук се намира Generic Repository + Частните repositories за таблиците които се нуждаят освен от нещата в Generic Repository, а и от др. частни за конкретната таблица методи

- папка с Repository Interfaces - интерфейси на всички repositories

- папка с Unit of work - тук ми се намира контекста на всички Repositories (на практика този контекст ще се ползва в външния проект. Дали той е MVC, Web Forms, Win app, WPF Или нещо др. това няма значение)

Web Application - Web Forms

- най-грубо казано тук са ми страниците който естествено ползват за контекст UnitOfWork класа ми който дава възможност да се използват методите във всички repositories. Това ми върши страхотна работа, обаче вече се достига до там че ако искам да направя пълния бизнес процес ще ми трябват методи които да правят такива неща че няма как да ги напиша в repositories- защото те не знаят за контекста и това е идеята да не знаят.

Та въпроса е.. тези методи които трябва да имат информация за Models + Data и чрез нещата в тях да се напишат такива методи които да ми позволят аз да правя някакви справки, калкулации и др. неща който няма как да ги взема от Data.

Имам няколко варианта които се сещам които биха свършили работа но незнам дали това не е лошо за целия дизайн.

1. Мога в Web Application проекта да си направя Utility class който да ми съдържа всички методи необходими ми за реализирането на бизнес логиката на проекта и да го достъпвам чрез референция.

2. Мога да направя отделен namespace в Data където там ще си направя този клас с многото методи.

3. Мога да направя съвсем отделно class library което да е единствено пълно с класове които да ги ползвам тях за тези големите бизнес методи който искам да напиша.

Kой от тези варианти е добър и защо. И ако тези не са добри защо и какво се препоръчва да се направи.

ПС: Това го искам защото не искам да си пълня бизнес логиката с някакви методи които са единствено с цел взимане на по сложни данни от базата и да ги слагам във формите а просто да ги достъпвам от отвън :)

 

Благодаря за отделеното време и се надявам да ми помогнете.

Благодаря предварително.

 

0
d0m1na7or avatar d0m1na7or 1 Точки

Можете да затваряте темата явно никой няма да отговори а и сигурно темата е вече на мноо дълбока страница:) аз и без това вече си реших проблема :)

0