这是一个很好的应用设计吗？ [英] Is this a good application Design?
问题描述
您好，
目前我的应用程序有三层 -
1.表示层（Asp.Net / Win Forms / Pocket PC） UI。）
这主要包含用户控件，自定义控件和Win / Web
表格。
我有一个基本表格，我继承自那个表格。
所有验证都在这个层次完成。此
层中没有数据访问代码。此层专门获取DataViews / Arays / Lists作为输入。输出
是带有SQL语句的字符串对象，或只是带有
dataconnection键的参数。
2.业务层。
目前这只是一个位于同一台机器上的图书馆
表示层。最终我计划使用Web服务，如果应用程序需要物理分离。
大多数业务逻辑都在这一层实现。这里绝对没有
UI代码。
这些都是执行CRUD功能的一堆静态方法。
所有方法都是原子性的。我不依赖静态变量。
只有一个DatabaseGateway类可以完成所有功能。
3.数据层。 （SQL Server）
我不使用存储过程。主要使用视图。
我一直在阅读Rockford Lhotka的业务对象，我觉得他的框架不必要地复杂化了。我只是不认为需要这些中间商务对象。
感谢您的回复。
-
Jay Balapa
软件工程总监
www.atginc.com
Hello,
Currently my application has three tiers-
1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
This predominantly contains User Controls, Custom Controls and Win/Web
Forms.
I have one base form and I inherit from that form.
All validation is done in this tier. There is zero Data Access code in this
tier. This tier exclusively gets DataViews/ Arays/Lists as input. Outputs
are string objects with SQL Statements or just paremeters with
dataconnection key.
2. Business Layer.
Currently this is just a Library residing in the same machine as
Presentation layer. Eventually I plan to use WebServices if application
needs physical seperation.
Most of Business Logic are implemented in this layer. There is absolutely no
UI code here.
These are all bunch of static methods which perform CRUD functionality.
All methods are atomic in nature. I dont rely on Static Variables. There is
just one DatabaseGateway class which does all the functionality.
3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.
I have been reading up on Rockford Lhotka''s business objects and I just feel
that his framework is unnecessarily complex. I just dont see the need to
hold these intermediate Business Objects.
Thanks for your responses.
--
Jay Balapa
Director Of Software Engineering
www.atginc.com
推荐答案
您的SQL应该在业务层中。表示层不应该生成或提供有关如何收集数据的决策（使用哪些表/视图
或列），因为这是业务规则。 />
" Jay Balapa" < JB ***** @ hotmail.com>在消息中写道
news：％2 **************** @ tk2msftngp13.phx.gbl ...
Your SQL should be in the Business Layer. The presentation layer should not
make or provide decisions on how data is collected ( that what tables / view
or columns are used ) as that is a business rule.
"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
你好，
目前我的应用程序有三层 -
1.表示层（Asp.Net / Win Forms / Pocket PC UI。）
这主要包含用户控件，自定义控件和Win / Web
表单。
我有一个基本表单，我从该表单继承。
所有验证都在此层中完成。
此层中没有数据访问代码。此层专门将DataViews / Arays / Lists作为输入。
输出是带有SQL语句的字符串对象，或者只是带有数据连接密钥的参数。
2.业务层。
目前，这只是一个与图书馆层位于同一台机器上的图书馆。最终，如果应用程序需要物理分离，我计划使用WebServices。
大多数业务逻辑都在这一层实现。这里绝对没有UI代码。
这些都是执行CRUD功能的一堆静态方法。
所有方法本质上都是原子的。我不依赖静态变量。
只有一个DatabaseGateway类可以完成所有功能。
3.数据层。 （SQL Server）
我不使用存储过程。主要使用视图。
我一直在阅读Rockford Lhotka的业务对象，我只是觉得他的框架不必要地复杂。我只是不认为需要这些中间Business Objects。
感谢您的回复。
-
Jay Balapa
软件工程总监
www.atginc.com
Josh，
感谢您的回复。
SQL大部分时间都在Business层中。
有时我需要在Datagrid中迭代Datarows。在那些情况下，我将
作为例外。
-
Jay
Josh ; < s@a.com>在消息中写道
news：OS ************** @ TK2MSFTNGP10.phx.gbl ...
Josh,
Thanks for your response.
SQL most of the time is in the Business layer.
Sometimes I need to iterate Datarows in a Datagrid. In those cases I make
that exception.
--
Jay
"Josh" <s@a.com> wrote in message
news:OS**************@TK2MSFTNGP10.phx.gbl...
你的SQL应该在业务层。表示层应该不做出或决定如何收集数据（使用哪些表格/视图或列），因为这是一项业务规则。
杰伊巴拉帕 < JB ***** @ hotmail.com>在消息中写道
新闻：％2 **************** @ tk2msftngp13.phx.gbl ...
Your SQL should be in the Business Layer. The presentation layer should
not make or provide decisions on how data is collected ( that what tables
/ view or columns are used ) as that is a business rule.
"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
你好，
目前我的应用程序有三层 -
1.表示层（Asp.Net / Win Forms / Pocket PC UI。）
这主要包含用户控件，自定义控件和Win / Web
表单。
我有一个基本表单，我从该表单继承。
所有验证都在此层中完成。
此层中没有数据访问代码。此层专门将DataViews / Arays / Lists作为输入。
输出是带有SQL语句的字符串对象，或者只是带有数据连接密钥的参数。
2.业务层。
目前，这只是一个与图书馆层位于同一台机器上的图书馆。最终，如果应用程序需要物理分离，我计划使用WebServices。
大多数业务逻辑都在这一层实现。这里绝对没有UI代码。
这些都是执行CRUD功能的一堆静态方法。
所有方法本质上都是原子的。我不依赖静态变量。
只有一个DatabaseGateway类可以完成所有功能。
3.数据层。 （SQL Server）
我不使用存储过程。主要使用视图。
我一直在阅读Rockford Lhotka的业务对象，我只是觉得他的框架不必要地复杂。我只是没有看到
需要持有这些中间Business Objects。
感谢您的回复。
-
Jay Balapa
软件工程总监
www.atginc.com
如果你想废除业务对象的复杂性，那么
考虑将此业务逻辑作为存储过程移动到数据库中，并且
触发器。
Jay Balapa < JB ***** @ hotmail.com>在消息中写道
news：％2 **************** @ tk2msftngp13.phx.gbl ...
If you want to do away with the complexity of the business objects, then
consider moving this business logic to the database as stored procedures and
triggers.
"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
你好，
目前我的应用程序有三层 -
1.表示层（Asp.Net / Win Forms / Pocket PC UI。）
这主要包含用户控件，自定义控件和Win / Web
表单。
我有一个基本表单，我从该表单继承。
所有验证都在此层中完成。此层的
中没有零数据访问代码。此层专门获取DataViews / Arays / Lists作为输入。输出
是带有SQL语句的字符串对象，或者只是带有数据连接密钥的参数。
2.业务层。
目前这只是一个驻留在同一台机器上的库作为表达层。最终，如果应用程序需要物理分离，我计划使用WebServices。
大多数业务逻辑都在这一层实现。这里绝对没有
没有UI代码。
这些都是执行CRUD功能的一堆静态方法。
所有方法本质上都是原子的。我不依赖静态变量。
只是一个DatabaseGateway类，它可以完成所有功能。
3.数据层。 （SQL Server）
我不使用存储过程。主要使用视图。
我一直在阅读Rockford Lhotka的业务对象，我只想
觉得他的框架不必要地复杂。我只是没有看到需要这些中间Business Objects。
感谢您的回复。
-
Jay Balapa
软件工程总监
www.atginc.com
这篇关于这是一个很好的应用设计吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
