Silverlight Application Project Structure - How much is too much? -


my team working on creating our first silverlight 4 application. first of give bit of detail on actual project. silverlight 4 designed run out-of-browser , using wfc data services our own implementation of dataobjects. (no entity framework, linq-to-sql, etc). have few consultants in recommending solution structure contains more 11 individual projects. there doesn't seem reason it, can see justification why following might needed?

  • project.client - assets, styles, views
  • project.common - converters, helpers
  • project.data - unknown purpose (client project)
  • project.infrastructure - commands, constants, interfaces, logging
  • project.majorfunctiona - "business logic major function of application"
  • project.majorfunctionb - "business logic major function of application"
  • project.majorfunctionc - "business logic major function of application"
  • project.models - abstracted access wcf services
  • project.uicontrols - custom controls ui
  • project.unittests - "potentially unit tests"
  • project.viewmodels - view models ui
  • project.web - host project silverlight app - no code
  • project.web.infrastructure - data objects , wcf services

now, our major confusion comes why wouldn't namespace things out keep them separate, things "project.majorfunctiona" small component of application, why should have own project. (keep in mind views , viewmodels specific function not live in project other client/viewmodel projects.

we looking validation, don't see reason this.

agreed: use namespaces logical organization, not projects. 1 approach think of projects units of deployment. project.client deployed project.viewmodels? project.models? 1 referencing other? include in same project , use namespaces organization.

a few reasons why may want separate silverlight class libraries/applications individual projects:

  • reuse. want develop apis used other applications. project.infrastructure may fall category.
  • modularity. majorfunctiona used end user 20% of time. maybe authenticated users have access. maybe access when navigated specific page noone goes to. choose build separate silverlight apps , download .xaps needed using frameworks mef or prism.
  • developer workflows. 1 team in 1 city/office working on project.client , team in city/office working on project.models. might make sense build separate projects make life easier.

one other thing note assemblies can't have circular references between assemblies. in other words, if classa , classb in same assembly, classa can reference classb, , classb can reference classa. if they're in separate assemblies, can't. now, if classes have lot of circular references, that's not thing, it's difficult avoid, , options more limited if happen in separate assemblies. on flip side, increasing number of assemblies limits opportunity circular references, can improve quality of design. else aware of.

following logic, 1 alternative grouping project.client, project.data, project.model, project.uicontrols, , project.viewmodels in 1 project , grouping project.common , project.infrastructure another. majorfunctions left separate or grouped project.client. end with:

  • project.client - application specific interface, view models, , models.
  • project.infrastructure - common, reusable helpers, converters, , interfaces.
  • project.unittests
  • project.web
  • project.web.infrastructure

also. there's not correct answer this. i'm tagging community wiki.


Comments

Popular posts from this blog

c++ - Convert big endian to little endian when reading from a binary file -

C#: Application without a window or taskbar item (background app) that can still use Console.WriteLine() -

unicode - Are email addresses allowed to contain non-alphanumeric characters? -