3

Consider an MVC4/EF5 project:

  • Creating a web application which will have 3 modules.
  • Based on the customer license, we will enable or disable 1-3 of the modules.
  • Each of the modules will deal with a handful of common tables (Users, Company, etc).
  • Each of the modules will deal with tables specific to their functionality (PO's, Timesheets, etc)
  • An admin portal, admin users in a seperate table from regular users.
  • data passed to views using view models
  • eventually there will be a JSON service for exposing parts of the applications functionality.
  • There will be multiple deployments of this application with slight customization (beyond just enabling/disabling each of the three modules).

The Plan so far:

  • Separate dll for Model
  • Separate dll for each Module/Functional area.
  • Separate dll for the ViewModels
  • Separate dll for admin portal
  • Seperate dll for the web service

Questions:

  1. Is anything gained by a seperate dll for ViewModels?
  2. Tips for managing multiple variations of the same application, with regards to project organization, and source control?
  3. Should there be a separate dll for authentication (membership and role providers)?
  4. Any other thoughts? (Sorry for the open ended/loaded question, maybe I should remove this one)
sheamus
  • 3,001
  • 4
  • 31
  • 54
  • You are thinking in right direction. Also look at nopCommerce, they have implemented plugin based development model to make their development and deployment modular. – Pradeep Sep 18 '13 at 17:40
  • Might also be worth looking at FeatureFlags if you are hosting the application for them. If you put features behind them then you can enable/disable them per user. – Matthew Steeples Sep 18 '13 at 18:33
  • Have a look at my question here it covers some of the issues http://stackoverflow.com/questions/10428300/what-is-a-good-solution-structure-to-allow-easy-customisation-of-a-product-on-a – GraemeMiller Sep 19 '13 at 00:20
  • @sheamus anything else I can do to help on this question? – GraemeMiller Sep 24 '13 at 21:03

1 Answers1

3

My advice:

  • Don't try to solve your problems with Source Control. Unless you are really good with branching/merging and very very disciplined. I'd recommend one code base that is pulled together with Di/IoC
  • DI/IoC lots and lots of it - Look at Autofac and the Mutli-tenancy extra. Keep everything loosely coupled as much as possible
  • Testing - TDD as everything needs to be loosely coupled lots of testing - look at Autofixture/AutoMoq
  • Extension points galore - layers of re-direction are your friend as everyone will want different implemenations. Our core architectural elements is a CQRS light style - Commands, Command Validators, Queries, and Domain Events
  • Keep everyone on the same database structure (unless you go NoSQL etc)
  • Use Onion Architecture - Make 3 projects, Web (MVC5/WebAPI/ViewModels), Infrastructure (all the technical stuff Repository implemenations etc), Domain Layer
  • Then make projects per client with overrides - e.g. Custom ITimeSheetCalculator etc
  • Include ViewModels in Web Project - Look at per tenant ViewModel mappings if required. Use AutoMapper
  • Look at stuff like VirtualPathProvider EmbeddedVirtualPath provider so you can put views CSS in client DLL
  • Create an Ambient Configuration file that defines what is turned on per tenant. Feature toggles will be required. Especially during dev for features not yet complete
  • Find yourself a canary - a client you can work with on a beta version who you trust and can give good feedback
  • For security look at using Claims Based Identity - comes baked into MVC5. Makes it easier to have different security rules pre tenant etc
  • If you are working with multiple clients and they all want different features/or same feature but implemented differently you need get the strongest person you can get to gather requirements. You can't do traditional Scrum and have developers etc and work directly with all the clients. You need someone in your company acting as proxy product owner who will take ownership of the problem of getting all clients to agree on general features
  • Consider Azure has lots of nice features we have used. Easily allows scale up and down.

Good luck

Steven
  • 166,672
  • 24
  • 332
  • 435
GraemeMiller
  • 11,973
  • 8
  • 57
  • 111