Re: Architectural feedback
From: Brandon Potter (msnews_at_brandonpotter_nospam.com)
Date: 01/10/05
- Next message: EMW: "Three tables to one"
- Previous message: Dave: "mouse capture"
- In reply to: John Spiegel: "Architectural feedback"
- Next in thread: John Spiegel: "Re: Architectural feedback"
- Reply: John Spiegel: "Re: Architectural feedback"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 10 Jan 2005 15:47:03 -0500
You are already aware of the scope creep and "my God, the code has become so
entangled that we have to start over" possibilities of a project like this.
With that said, have you thought about possibly using a plugin-based system
for this app? The main app (.exe) is simply a skeleton that defines which
and what order other assemblies are loaded in. If you're not familiar with
Interfaces, you would be well served in the long run to take 2 months and
get comfortable there before tackling it. Ever seen Microsoft CRM? Might
look at that for UI ideas.
Brandon
"John Spiegel" <jspiegel@YETANOTHERSPAMHATERc-comld.com> wrote in message
news:%23wQDPUz9EHA.3980@TK2MSFTNGP11.phx.gbl...
> Hi all,
>
> I'm in the early stages of designing a system that we'll use in-house and
am
> looking for opinions and suggestions for further reading on which
directions
> to take.
>
> Background: Though we're a small company, I'd like to design this with
the
> mindset of a larger company from the start. This will be an ongoing
project
> to encompass a lot of needs, which will generally be variations on
standard
> themes: Customer account management, billing, reporting and other fairly
> common business functions. Most functionality will be accessed from our
LAN
> with WinForms-based apps (assume all client machines are Windows running
at
> least 2000). There will be some limited Web access for employees, e.g.,
> order forms for sales staff. While we may eventually want to build some
Web
> services for sharing informtion, the general pulic website will remain
> fairly autonomous.
>
> The nature of the company and application is that there will be fairly
> frequent releasing of the system, or components thereof.
>
> Current leanings: Most of the functionality will probably APPEAR to be
> (from user standpoint) unified under a single app. There are a number of
> underlying components into which this apparent monolith will actually be
> broken. Aside from various departmental boundaries that will make for
nice
> conceptual breaks. Utilities, e.g., common dialogs, data access and
account
> calculations, will be broken into various solutions. I'm thinking that
> there will be a skeleton client app that provides the system navigation,
> security and user preferences then uses the appropriate other resources to
> provide actual functionality.
>
> A lot of my uncertainties are in determining what forms and in what
> locations the pieces should be. For example, I'm not clear on whether the
> core app must reside on the client or may be run from the server. Is it
> better to leave the individual dll's on the server, or install in each
> client's GAC? My guess is that deploying all components to individual
> clients will give notably better performance. On the downside, that would
> imply updating a number of machines every time we add a new or function.or
> want to release bug fixes.
>
> I've read a fair amount on remoting, serviced components, and related
> functional divisions (a 70-320 prep book, mainly), but have seen little
that
> really ties together when the best situations to use each are.
>
> TIA,
>
> John
>
>
- Next message: EMW: "Three tables to one"
- Previous message: Dave: "mouse capture"
- In reply to: John Spiegel: "Architectural feedback"
- Next in thread: John Spiegel: "Re: Architectural feedback"
- Reply: John Spiegel: "Re: Architectural feedback"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
