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
Post a Comment