c# - Static Repositories - Workaround -
first, background. have taken on large mvc3 project. project pretty ready go live time ago, client decided wanted re-theme whole website , add load more functionality. employed re-theme site, finish off remaining functionality , deploy it.
generally built using clear, ordered approach, 1 repository each database table , clear service layer, there oddities making me uncomfortable. main oddity keeps on nagging @ me every single repository , service in application completely, 100% static (yes, including methods write db). of course, doesn't allow unit testing, greater concern potential bottlenecks , threading issues cause when application comes under heavy load. seeing unexplained delays in processing requests on stage server, , trickle of testing traffic.
the application huge rebuilding use ioc/instantiated-per-request repositories pretty out of question.
what can avoid potential threading issues upon deployment? use connection pool , borrow db connection each time write needs happen?
thanks in advance :)
edit - here of code creates instance of entity model. each static method calls 'demoentities' method obtain instance of entity model, uses execute db commands. can see here that, though method static, checking httprequest pre-existing instance , creating 1 if doesn't exist. such, think we'll ok.
public static demoentities demoentities { { if (httpcontext.current != null && httpcontext.current.items["demoentities"] == null) { httpcontext.current.items["demoentities"] = new demoentities(); } return httpcontext.current.items["demoentities"] demoentities; } set { if (httpcontext.current != null) httpcontext.current.items["demoentities"] = value; } }
`
pat
i assume here repository classes contain static methods, not static state.
the benefit of stateless static classes can safely turned regular classes default parameterless constructors , no concerns on life-span. simple case extract interface testing purposes.
whenever need talk repository, instantiate one.
unless application doing shared state during repository use, should not need concerned multi-threaded access. database responsible handling many concurrent calls.
currently bottlenecks , threading issues potential, our educated guesses @ possibly go wrong themselves wrong - multi-threading. slow down might because database doesn't have grunt cope many requests.
Comments
Post a Comment