I agree. I see WCF middle tier is used so often for no good reason. I would just create an MVC Web API controllers for the mobile app (and future other clients) and have logical tiers, not physical, for business logic.
On Wed, Mar 20, 2013 at 7:27 PM, <stacy.andr...@iinet.net.au> wrote: > My 2 Cents... > > This seems over-engineered. > > If I were designing this... I would create new WCF services/ web api > controllers for the mobile clients and remove the WCF middle tier. > > Stacy Andrews > (first time poster, long time reader ;)) > > > ----- Original Message ----- > From: > "ozDotNet" <ozdotnet@ozdotnet.com> > > To: > "ozDotNet" <ozdotnet@ozdotnet.com> > Cc: > > Sent: > Wed, 20 Mar 2013 12:27:45 +1000 > Subject: > Re: nTier ASP.NET MVC Application Architecture > > > > Thanks for comments and advice Nathan. > > Your idea of DAL between WCF Service and MVC Controllers is a good one, > and it does mimic how i have this set up currently (not explained properly > previously - sorry).. I have my wcf services accessible only from within my > SessionRepository objects. So the controller interacts only with the SR's > and the SR talks to the WCF services. > Comments on abolishing wcf layer seem sound, I was looking into the dual > interfaces to the business layer (1 from mobile and 1 from mvc web). I > haven't had the opportunity to explore Web API yet, but it looks like that > opportunity has just presented itself.. > > fyi.. ViewModels packaged in same dll as models (for convenience).. not > used in wcf services or as a DTO.. > I agree with your "_never_" sentiments.. > > thanks again.. > Grant > > > On Wed, Mar 20, 2013 at 11:35 AM, Nathan Schultz <milish...@gmail.com>wrote: > >> The last time I wrote an MVC app which included an iPhone client, the >> architecture looked similar to yours. Although I would _never_ have a >> view model in the WCF project, since a View Model has everything to do >> with presentation, and nothing to do with data access. I always have a >> Mapper in the MVC project that maps all Models to View Models and >> vice-versa. >> >> I also consider a web-service really to be just another data >> repository, so I add a DAL in between the MVC Controller and WCF >> service. This means a controller is never tied to the web-service, so >> is independent of implementation. >> >> Now that MVC4 has the Web API available, I'd be tempted to abolish the >> WCF layer so controllers talk directly to the Business Layer. >> I would then just write Web API controllers that would service RESTful >> requests from a mobile client. This has the advantage of not having to >> share a DLL containing your Domain Types and enums. >> >> Regards, >> >> Nathan. >> >> >> On 20 March 2013 08:11, Grant Molloy <graken...@gmail.com> wrote: >> > Hi All.. >> > >> > Application architecture is an interesting and regularly debated topic >> among >> > developers.. >> > Everyone seems to have their own take on it based either purely on >> theory, >> > real world experiences, and as always, a mixture of both. >> > >> > The application started out as a simple enough hosted ASP.NET MVC >> > application where users would visit a website, register, log in, and >> work >> > online.. Simple enough.. >> > Recently there's been a change where the scope has creeped with "an eye >> for >> > the future", "maximise code re-use", etc.. Fair enough.. Great >> concept.. >> > >> > My dilemma now is what's the best architecture for this app now that we >> will >> > be (in the future -- when ever that gets here) accessing the system from >> > mobile devices, and probably not through the default ASP.NET MVC >> interface >> > that is currently being developed. >> > I've been looking around for a decent online example of an nTier >> ASP.NET MVC >> > application architecture, but most of the things I've found are all >> > basically single tier where the author accesses the database via DAL >> > directly from controllers. >> > >> > The app has morphed into the following Architecture... >> > >> > ------- ASP.NET MVC ------- >> > | View >> > | + --> MVC Helpers >> > | | >> > | Model >> > | | >> > | Controller >> > | + --> Constants, Enums & Helpers.. (Separate DLL) >> > | + --> Session Repository (in MVC Project) >> > | + --> Domain Types (Models & ViewModels) (Separate DLL) >> > ------- ------- ------- ------- ------- >> > \/ >> > | WCF Service Call... >> > /\ >> > ------- WCF Services SERVER ------- >> > | WCF Services >> > | | >> > | Business Layer >> > | | >> > | DAL >> > | + --> Domain Types (Models & ViewModels) (Separate DLL) [.. this >> is >> > the same dll as referenced by the Controller above] >> > | + --> Constants, Enums & Helpers.. (Separate DLL) [.. this is the >> > same dll as referenced by the Controller above] >> > ------- ------- ------- ------- ------- >> > | >> > ------- DATABASE Server ------- >> > | Database >> > ------- ------- ------- ------- ------- >> > >> > This architecture seems to be working fine for now and I know that i'm >> > probably going to have to change my WCF services to use a more RESTful >> > approach, or implement another more mobile friendly interface, to make >> it >> > easier for mobile connection, but that can happen down the track when >> i'm >> > ready for that part. >> > I'm also looking to use SQL CLR Types in the future so that I can be >> sure >> > that the data in reference tables (like say PhoneType, PencilType, >> CarBrand, >> > etc) mirror that exactly as in the Enums in the code. I've done some >> > preliminary investigations into this and it is feasible, but whether >> it's >> > worth it is another issue. >> > >> > How are people designing their ASP.NET MVC app architecture out there >> in the >> > wild ?? >> > I would love to hear/see your ideas/architecture.. >> > >> > Grant >> > >
