CODEWITHSUNDEEP
entity-frameworkentityrepository-pattern
bit
bit

Reputation: 963

UnitOfWork - IRepository - STE

I'm trying to implement a simple 3 tier application assembled as following:

1 - DAL (it's a UnitOfWork and IRepository, with POCO's entity (entity framework T4))

2 - BLL (reference to DAL)

3 - UI (reference to BLL)

I read many articles, so I decided to implement a classic UnitOfWork-Repository pattern, where those repositories doesn't aware about any self-tracking-entity:

public interface IRepository<T>
{
void Attach(T entity)
{
...
}

Questions: if my component will be run on winForm context, some UI control could chaning some entity property, so further call method of Repository as Edit(T entity) will be useless sice my entity is already being tracked by internal object context. Obviously, if I'm running on web context all works fine since web platform is stateless. A simple trick could be dispose my objectContext after every BLL operation, but I'm not sure to want use this workaround. So I'm looking for a more pretty solution in order to manage all cases.

Should IRepository ignoring anything about STE? Should BLL alway disposing its own internal repository and-or unit in order to simulate a stateless ambient?

Upvotes: 0

Views: 108

Answers (1)

brke
brke

Reputation: 116

If you're developing in WinForms why would you want to simulate stateless platform? Regarding Repository and UnitOfWork patterns, don't look at them as something strictly bound to EntityFramework. Forget about Context in your UI layer. Those patterns are independent of ORM used and are there so you could switch your DAL easily and to test your application more efficiently.

Upvotes: 1

Related Questions