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

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

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

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ой от тези варианти е добър и защо. И ако тези не са добри защо и какво се препоръчва да се направи.

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

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

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

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