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

Reply via email to