Featured post

c# - Usage of Server Side Controls in MVC Frame work -

i using asp.net 4.0 , mvc 2.0 web application. project requiremrnt have use server side control in application not possibl in noraml case. ideally want use adrotator control , datalist control. i saw few samples , references in codepleax mvc controllib howwver found less useful. can tell how utilize theese controls in asp.net application along mvc. note: please provide functionalities related adrotator , datalist controls not equivalent functionalities thanks in advace. mvc pages not use normal .net solution makes use of normal .net components impossible. a normal .net page use event driven solution call different methods service side mvc use actions , view completly different way handle things. also, mvc not use viewstate normal .net controlls require. found article discussing mixing of normal .net , mvc.

c# - API architecture -


i in process of designing api. know if have come solution:

i have respository type of data layer talks database converting business classes entities(generated llbl gen, didn't want use entities directly business objects because wanted keep them simple , allow me swap out entity framework or other mapper needed to)

i have wcf service layer i'm using type of facade. calls respository layer , converts business objects dtos , passes them through api service call via message client. client can aspx website, silverlight app, wpf app, or wp7 app. problem keep runnnig when want run business logic have send dto wcf service , client. doesn't seem "right" me. can't put business logic in dto because defeats purpose. if want business type code run on client have lot of duplication of code throughout different clients.

my business layer not know of data layer, data layer knows of business layer , facade layer knows of data layer , business layer , dtos. bad design api? , can offer me suggestions? have learned of enterprise level apps through reading different articles online.

thanks!

relations between layers

if understand design well, business layer not know of (=does not use) data layer, , facade interconnects them translating daos dtos , vice-versa.

you should consider rather different approach: define interfaces data-related objects (regardless if daos or dtos) , use inversion-of-control container weave business layer , data access layer together. reason in design might run inability retrieve additional data in right in business layer. you'd end facade substituting lack , hence doing actual business logic.

in case make clear connection between business layer , underlying data layer, while separating them well-designed interfaces , ioc container, prevent problem while maintaining , concise internal design.

usage of dtos

i think it's alright have pass dtos back-end of app. in case purpose of dtos (1) supply information presentation layer, , (2) provide way of passing modified or new data back-end further processing. dtos cases (1) , (2) need not same. hence if makes sense, can pass back-end dto representing subset of whole information.

however, back-end shall return new dto after processing, which, again, needs not same dto input dto. way presentation layer can adapt changes made back-end related parts of whole object.

imagine simple / update api such one:

customerdto getcustomer(int customerid);  customerdto updatecustomeraddress(int customerid, addressdto address);  customerdto updatecustomerprimarycontact(int customerid, persondto primarycontact); 

you using id identify customer , passing in dto represents subset of customer record updated (regardless of underlying data architecture). out dto represents customer whole, simplifying presentation-layer's task of updating information shown user. advantage back-end not need know subset of customer data presentation layer needs, , presentation layer can pass back-end parts modified.

update — technical note: consider using tool automapper (c#) automate translations between dtos , daos. while matter subject of technology used, approach saves lot of manual work , able eliminate hard-to-discover bugs. having such object translation automation in place helps promote better design practices , allows produce more-specialized , hence semantically more accurate dtos.


disclaimer: while rather general question, recommendations may not seem right in respect further details of application not covered in question.


Comments

Popular posts from this blog

c# - Usage of Server Side Controls in MVC Frame work -

cocoa - Nesting arrays into NSDictionary object (Objective-C) -

ios - Very simple iPhone App crashes on UILabel settext -