建筑反馈 [英] Architectural feedback

问题描述

大家好，


我正处于设计我们将在内部使用的系统的早期阶段，并且我正在寻找
关于进一步阅读哪些方向的意见和建议

。


背景：虽然我们是一家小公司，但我想从一开始就用大公司的

思维设计这个。这将是一个正在进行的项目

，以满足很多需求，这通常是标准的变化
主题：客户帐户管理，计费，报告和其他相当的

常见业务功能。大多数功能都将通过基于WinForms的应用程序从我们的LAN

进行访问（假设所有客户端计算机都在Windows上运行，至少
b）。员工将获得一些有限的Web访问权限，例如，销售人员的b
订单。虽然我们最终可能希望建立一些Web

服务来共享信息，但一般的网站将保持相当自主的价值。


公司和应用程序的性质是系统或组件的频繁释放将会非常有效。


当前倾向：大多数在单个应用程序下统一的功能可能会显示为
（从用户的角度来看）。有许多

底层组件，这些明显的巨石实际上将被打破。除了各种部门边界之外，还有很好的概念性休息时间。公用事业，例如，通用对话框，数据访问和帐户计算，将被分解为各种解决方案。我在想

会有一个骨架客户端应用程序提供系统导航，

安全性和用户首选项然后使用适当的其他资源来

提供实际功能。


我的很多不确定因素在于确定哪些形式以及这些作品应该在哪些位置。例如，我不清楚

核心应用程序是否必须驻留在客户端上，或者是否可以从服务器运行。将个人dll留在服务器上，还是安装在每个
客户端的GAC中，是否更好？
？我的猜测是，将所有组件部署到单个

客户端将显着提高性能。在缺点方面，每当我们添加一个新功能或功能时，这将意味着更新许多机器。或者

想要发布错误修复。


我已经阅读了相当数量的远程服务，服务组件和相关的功能部门（主要是70-320预备书），但很少见到/>
真正联系在一起，当最好的情况使用时。


TIA，


John

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

推荐答案

John，


当你没有工作人员，Oracle，SAP或Peoplesoft等你的

命令用于你想要做什么，而不是你写的这个有一个非常好的b / b
在我看来失败了。

John,

When you have not the staff equaly too Oracle, SAP or Peoplesoft to your
command for what you want to do, than will this what you write has a very
high change to fail in my opinion.

背景：虽然我们是一家小公司，但我想从一开始就设计一个大公司的思维模式。

Background: Though we''re a small company, I''d like to design this with
the
mindset of a larger company from the start.

微软为此购买了Navision。


你不是第一个尝试这一点的人，但是有人成功地获得了它的成功（通常是在第一次开发团队完成更新后）

新的（呃），因为项目确实花费了更多，并且比管理层预期的更多时间花了更多的时间。


但是我的观点只是我写的。


Cor

Microsoft has bought Navision for that.

You are not the first one who tries that, however there were who succeed in
it (often after a complete refreshment from the first developmentteam too
new(er) because the project did cost more and took more time than the
management had expected).

However just my opinion as I wrote.

Cor

Hey Cor，


像大公司一样留下了很多空间。我的意思是不是一个小的

公司。现在，我们只有大约15个客户端和一台服务器。

我正在谈论的只是记住像

的影响这样的事情服务器集群，将数据库服务器从应用程序中分离出来。

服务器和/或引入更专用于某些

流程/部门以及如何共享资源的服务器。我们不是要为大众建立一个全面的系统。


我们拥有现有系统的奢侈品这将满足当前的需求

以及可预见的未来。这个新项目将是一个持续的，
的长期项目，将与现有的项目一起工作一段时间，以获得
。它首先会主要添加当前

缺乏的新功能，但随着时间的推移，将吸收当前的功能。


原因很多，但是（假设你不想在一个你不关心的公司内部工作的论文上）我认为我们有足够的

理由看看沿着这条路走下去。


谢谢，


John


我们有一个现有的VFP系统，诚实地满足我们对一些

时间的需求。

" Cor Ligthert" <无************ @ planet.nl>在消息中写道

news：ea ************** @ TK2MSFTNGP11.phx.gbl ...

Hey Cor,

"Like a large company" leaves a lot of room. What I meant is "not a tiny
company". Right now, we''ve only got about 15 clients and a single server.
I''m talking about just keeping in mind things like the effects of having a
server cluster, separating out the database server from application
server(s) and/or introducing servers that are more dedicated to certain
processes/departments and how to share resources. We''re not trying to build
an end-all-be-all system for the masses.

We have the luxury of having an existing system that will meet current needs
as well as the foreseeable future. This new project will be an ongoing,
long-term one that will work in tandem with the existing for some time to
come. It will at first, mainly add new functionality that the current
lacks, but as time goes on, will absorb the functions of the current.

The reasons are many, but (assuming you don''t want a dissertation on the
inner workings of a company you don''t care about) I think we do have enough
justification to look at heading down this path.

Thanks,

John

We have an existing VFP system that honestly would meet our needs for some
time to come.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:ea**************@TK2MSFTNGP11.phx.gbl...

John，
当你没有工作人员将Oracle，SAP或Peoplesoft等同于你想要做的命令时，那么你所写的内容将会非常有效我的意见。

John,

When you have not the staff equaly too Oracle, SAP or Peoplesoft to your
command for what you want to do, than will this what you write has a very
high change to fail in my opinion.

背景：虽然我们是一家小公司，但我想用以下大公司的思维来设计这个公司。开始。
微软已经为此购买了Navision。

你不是第一个尝试这一点的人，不过有成功的人

Background: Though we''re a small company, I''d like to design this with
the
mindset of a larger company from the start.
Microsoft has bought Navision for that.

You are not the first one who tries that, however there were who succeed

in它（通常是在第一次开发团队完全更新之后）（因为项目确实花费的成本更多，花费的时间比管理层预期的更多）。

然而我的意见正如我所写的那样。

Cor

in it (often after a complete refreshment from the first developmentteam too
new(er) because the project did cost more and took more time than the
management had expected).

However just my opinion as I wrote.

Cor

John，

如此浑水我更多 - 你关心当

服务器出现故障时会发生什么？ （他们是这样）。这会影响你的设计。例如，

银行分行绝对必须能够使用失败的服务器（或

连接到它）。这意味着在这种情况下，

客户端上的许多功能都是重复的。 （但升级很少进行 - 有时几年

分开 - 因为升级的痛苦）。

基本上，关于何时使用，没有任何好的指导方针因为这可能是如此依赖于具体情况。

BTW，试图预测应用程序中的未来增长和功能

（在我的经历中，更多的大公司喜欢是一个很好的做法。

Bob Milton


" John Spiegel" < JS ****** @ YETANOTHERSPAMHATERc-comld.com>在消息中写道

新闻：％2 **************** @ TK2MSFTNGP11.phx.gbl ...

John,
Just to muddy the water some more - do you care what happens when the
server goes down? (They do). That can influence your design. For example,
bank branches absolutely must be able to function with a failed server (or
connection to same). This means a lot of functionality is duplicated on the
clients just for this case. (But upgrades are done rarely - sometimes years
apart - because of the pain of upgrading).
Basically, there aren''t any good guidelines as to when you use which
approach since that can be so dependent on the specific situation.
BTW, trying to foresee future growth and features in your application
(being more "large company like") is a good practice in my experience.
Bob Milton

"John Spiegel" <js******@YETANOTHERSPAMHATERc-comld.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

大家好，

我正处于设计系统的早期阶段，我们将在内部使用，并且
我正在寻找意见和建议，以便进一步阅读
方向


背景：虽然我们是一家小公司，但我想用

心态设计这个从一开始就是一家大公司。这将是一个持续的
项目，以满足很多需求，这通常是标准主题的变化：客户帐户管理，计费，报告和其他相当的
常见的业务功能。大多数功能都将通过基于WinForms的应用程序从我们的
LAN访问（假设所有客户端计算机都在Windows上运行
至少2000）。员工将获得一些有限的Web访问权限，例如，销售人员的订单。虽然我们最终可能希望建立一些用于共享信息的网站服务，但一般的网站将保持相当自治。

公司的性质和应用是否会相当频繁地发布系统或其组件。

目前的倾向：大多数功能可能会（从用户的角度来看）统一在一个应用程序下。有许多基础组件，这些明显的巨石实际上将被打破。除了各种部门的界限，这将构成很好的概念性休息。公用事业，例如，通用对话框，数据访问和帐户计算，将被分解为各种解决方案。我在想，
会有一个骨架客户端应用程序提供系统导航，安全性和用户首选项，然后使用适当的其他资源来提供实际功能。

很多我的不确定因素在于确定这些作品的形式和位置。例如，我不清楚
核心应用程序是必须驻留在客户端上还是可以从服务器运行。最好是将个人dll留在服务器上，还是安装在每个客户端的GAC中？我的猜测是，将所有组件部署到单个客户端将会显着提高性能。在缺点方面，每当我们添加新的或功能时，这意味着更新许多机器。或者想要发布错误修复。

我读了一个关于远程服务，服务组件和相关功能部门的合理数量（主要是70-320预备书），但是当最好的情况下使用每个部分时，我们看到的确很少联系在一起是。

TIA，

John

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

这篇关于建筑反馈的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！