CodeSmith Community
Your Code. Your Way. Faster!

Shared vs. Project Namespaces

Latest post 10-10-2007 3:01 PM by evali. 3 replies.
  • 01-30-2007 5:27 AM

    • Tyrven
    • Not Ranked
    • Joined on 01-30-2007
    • Redmond, WA
    • Posts 8
    • Points 160

    Shared vs. Project Namespaces

    Summary: Allow users to define a shared namespace in addition to the current project namespace parameter so that shared components are not duplicated in server environments including multiple base namespaces representing various companies, teams, projects or technologies.

    Background: Currently, all files generated use the same base namespace.  This makes sense assuming that there is a single database representing a single company/project/application - as is probably the case for many users.  However, I work in an environment where a) many developers maintain different applications each with their own database backend, and b) multiple logical namespaces (based on distinct projects, technologies or companies) may be represented.  In this scenario, all of the base/abstract classes, interfaces, shared utilities, etc are regenerated for each project.  This obviously creates a lot of overhead and duplication. 

    A simple solution would be to allow two configuration parameters: one for the shared namespace and another for the project namespace.  The shared namespace might default to something like "NetTiers" to make it clear that these files were not specific to any particular implementation.  Personally, I'd be fine having it hardcoded to "NetTiers", but keeping it as a parameter would allow flexibility for users who prefer the current model or, for example, may need multiple versions of the shared libraries (as may be the case if one group has made notable edits to the shared class library templates).

    Code Impact: This would be an easy edit without a significant impact on backwards compatibility.  It would also have the additional benefit of making it easier for new users to sort through the code as it would be more evident which code was generic/shared and which was specifically generated for this particular project.

    Jeremy 

    • Post Points: 5
  • 02-06-2007 5:08 AM In reply to

    • Tyrven
    • Not Ranked
    • Joined on 01-30-2007
    • Redmond, WA
    • Posts 8
    • Points 160

    Re: Shared vs. Project Namespaces

    Any thoughts on this?  Currently, this is the only roadblock preventing widescale use of .nettiers in the organization I work with, and I think it'd be benefitial to other users who work in multi-application environments.
    • Post Points: 35
  • 03-02-2007 4:28 AM In reply to

    • Tobi
    • Not Ranked
    • Joined on 12-03-2006
    • Posts 3
    • Points 105

    Re: Shared vs. Project Namespaces

    Tyrven,

    I share your thoughts, we have a large system which has multiple problem domains and separate modules. What we would like is for all the core code to be set in some bases classes. Then when the particular tables are generated they reference the shared libraries thus reducing the amount of code duplicated to a bare minimum.

    This would also allow our dev teams to work on discreet areas of the platform without impacting others

    One this that has really bugged me is the Web data controls, they are repeated each time you generate a set of tables. They can't imported via the web.config file as they clash so they need separate references in the page. There really should be a common library for the controls.

    I would love to have the time to help out on this but unfortunately I have too many projects on the go.

    Regards

    Tobi

    • Post Points: 35
  • 10-10-2007 3:01 PM In reply to

    • evali
    • Top 500 Contributor
    • Joined on 12-15-2005
    • Posts 9
    • Points 135

    Re: Shared vs. Project Namespaces

    Tobi,

    I'd like to do the same: have all the core code to be set in some bases classes. Any implementation on this using Nettier?

    Thanks!

     Eva

    • Post Points: 5
Page 1 of 1 (4 items) | RSS
Copyright © 2008 CodeSmith Tools, LLC
Powered by Community Server (Commercial Edition), by Telligent Systems