asp.net mvc - Which data layer / handling architecture or pattern to choose for a non-enterprise web application? (MVC / EF) -

asp.net mvc - Which data layer / handling architecture or pattern to choose for a non-enterprise web application? (MVC / EF) -

i need help in making design selection application. it’s straightforward web application, not enterprise class or enterprise-anything.

the architecture standard mvc 5 / ef 6 / c# asp.net, , pages talk back-end database that’s in sql server, , tables have corresponding entity objects generated vs 2013 using ef designer , don’t see changing anytime in near future. hence creating super abstract “what if database changes” etc. separations perchance pointless. i one-man operation we're not talking huge teams etc.

what want clean way crud , query operations on database, using dbcontext , linq operations – i’m not database related code design. here approaches

1. static class methods - should create static class (my dal) holds datacontext , provide functions controllers can phone call directly

e.g. mystaticdblib.getcustomerbyid(id)

but poses problems when seek update records disconnected instances (i.e. create object json response , need ‘update’ table). thing can centralize operations in lib or dal file. getting complicated , messy, because can’t create methods every scenario end bits of linq code in controllers, , bits handled these lib methods

2. class context, held in singleton, , called controller

mycontext _cx = mystaticdblib.getmycontext(“sessionkey”); var xx = cx.mytable.find(id) ; //and other linq operations

this feels bit messy info query code in controllers @ to the lowest degree have clean context each session. other thinking here linq-to-sql abstracts info layer extent long entities remain same (the actual store can change), why not this?

3. utilize generic repository , unitofwork pattern – we’re getting fancy. i’ve read bit pattern, , there’s many different advises, including suggesting ef6 builds repository context hence overkill etc. sense overkill need here tell me given context

4. else? other clean way of handling basic database/crud

right have library type approach (1. above) , it's getting increasingly messy. i've read many articles , i'm struggling there's many different approaches, hope context i've given can elicit few responses approach may suit me. need maintain simple, , i'm one-man-operation near future.

absolutely not #1. context not thread safe , wouldn't want static var in static class. you're asking application explode.

option 2 workable long ensure singleton thread-safe. in other words, it'd singleton per-thread, not entire application. otherwise, same problems #1 apply.

option 3 typical short-sighted. repository/unit of work patterns pretty much replaced having orm. wrapping entity framework in layer removes many of benefits of working entity framework while simultaneously increasing friction involved in developing application. in other words, it's lose-lose , unnecessary.

so, i'll go #4. if app simple enough, utilize context directly. employ di container inject context controller , create request-scoped (new context per request). if application gets more complicated or really, don't care having dependency on entity framework, apply service pattern, expose endpoints specific datasets application needs. inject context service class(es) , inject service(s) controllers. hint: service endpoints should homecoming fully-formed info has been queried database (i.e. homecoming lists , similar enumerables, not queryables).

asp.net-mvc linq entity-framework