寻找有关SMALL网站数据访问的最佳实践建议 - 而不是企业 [英] Looking for best practice advice on data access for SMALL web sites - not enterprise
问题描述
您好，
MSDN（以及其他地方）充满了有关如何获取数据的有用建议
访问权限，但它们似乎都适合于病房企业应用。也许
我是少数人，但我没有那种客户。我的都是
小型企业，其网站永远不会达到这种规模。我和b $ b处理那些网站每天可能会有几百个访问者（有些甚至没有那么多）并且每天获得不超过10个订单的企业。
这不是企业级别，不需要编码的重量
和企业应用程序需要的层。
我正在寻找获取小型网站最佳做法指南。我独自工作，
并且不太可能改变它，所以额外的层和编码的重量
来保护数据库免受编码表示层的人
不是必需的。我很乐意将应用程序分成几层，但只有在有一些真正的好处的情况下才能获得
。我见过的大多数建议涉及
构建数据访问层，业务逻辑层和演示文稿
层。对于一个由一个人b $ b人维护的小网站来说，这似乎是最重要的。
到目前为止，我已将.aspx文件视为表示层，
代码隐藏（以及.aspx文件中的客户端验证）作为业务逻辑层的
，并且在实用程序中具有通用方法
实际与数据库通信的函数。我想知道
这是不错的做法，还是有更好的方法。
我一直在阅读
的教程<一个rel =nofollowhref =http://www.asp.net/learn/dataaccess/\"target =_ blank> http://www.asp.net/learn/dataaccess/ 他们似乎热衷于在Visual Studio中使用
数据表对象，它允许您在不编写代码的情况下创建与数据库的
连接。他们还构建了一个逻辑
图层，这在我的情况下似乎是不必要的，但我愿意接受教育的
!!
欢迎任何和所有评论。请记住，我不是*写给企业的
，我正在为小型网站寻找最佳解决方案。
TIA
-
Alan Silver
（此行下面添加的任何内容都与我无关）
Hello,
MSDN (amongst other places) is full of helpful advice on ways to do data
access, but they all seem geared to wards enterprise applications. Maybe
I''m in a minority, but I don''t have those sorts of clients. Mine are all
small businesses whose sites will never reach those sorts of scales. I
deal with businesses whose sites get maybe a few hundred visitors per
day (some not even that much) and get no more than ten orders per day.
This is not enterprise level and does not require the weight of coding
and layers that enterprise applications need.
I''m looking for a guide to best practices for small sites. I work alone,
and am unlikely to change that, so the weight of extra layers and coding
to protect a database from the person coding the presentation layer
isn''t necessary. I am happy to split the application into layers, but
only where there is some real benefit. Most advice I have seen involves
building a data access layer, a business logic layer and a presentation
layer. This seems over the top for a small site maintained by one
person.
Up until now, I have treated the .aspx file as the presentation layer,
the code-behind (and the client-side validation in the .aspx file) as
the business logic layer, and have a generic method in a utilities
function that actually communicates with the database. I want to know if
this is good practice, or if there is a better way.
I have been reading the tutorials at
http://www.asp.net/learn/dataaccess/ and they seem keen on using the
Data Table object in Visual Studio that allows you to create a
connection to a database without writing code. They also build a logic
layer, which seems unnecessary in my case, but I am willing to be
educated!!
Any and all comments welcome. Please remember, I am *not* writing for
the enterprise, I am looking for the best solution for small sites.
TIA
--
Alan Silver
(anything added below this line is nothing to do with me)
推荐答案
我发现使用3层
方法构建网站（甚至是小网站）是更多的工作，但它更容易保持不变。你的
代码更清晰，更容易通过你不想要的东西弹出来了，这有时可以帮助你节省时间
比花更长的时间。
我已经两种方式，现在我严格执行3层方法。我是
通常也是唯一的开发者。这是我的2美分。
-Darren Kopp
I''ve found that building websites (even small ones) with the 3-tier
approach is more work, but it''s a lot easier to maintain as well. Your
code is a lot cleaner and easier to go through when something pop''s up
that you didn''t expect, which can sometimes help you save time rather
than it taking longer.
I''ve done both ways, now i do strictly do the 3-tier approach. I''m
typically the only developer as well. That''s my 2 cents.
-Darren Kopp
我唯一不同的是小与企业相比，我有时会创建子文件夹而不是实际的不同程序集。
http://sholliday.spaces.msn.com/PersonalSpace.aspx 6/5/2006
5 / 24/2006
（这是我的等级系统的例子）
对比企业 vs小应用程序
企业将:(对于虚构的NorthwindManager应用程序）
GranadaCoder.Applications.NorthwindManager.Present ation.Web.1
GranadaCoder.Applications.NorthwindManager.Present ation.Winforms1
GranadaCoder.Applications.NorthwindManager.Busines sLogic
GranadaCoder.Applications.NorthwindManager.Data
（以上各项都是单独的组装）
对于小型应用程序..我有1个申请：
GranadaCoder.Applications.NorthwindManager
然后是不同的文件夹：
GranadaCoder.Applications.NorthwindManager.Web
GranadaCoder.Applications。 NorthwindManager.Biz
GranadaCoder.Applications.NorthwindManager.DAL
你会注意到一些事情：
1：我在small-app方法中不能有2个表示层。我可以
有1，因为我必须选择Web或Winforms并自己嫁给它。
2. Biz包含业务对象，逻辑
3.数据包含返回的对象（DataSet，IDataReader'，Scalars，
和空洞/ nothings）
这笔交易是在这样做之后许多企业应用程序，我知道什么时候
我正在宣传这些规则。
很有可能将业务对象扔到数据层有时候，
这在企业设置中是不可能的，因为.Data没有
参考.BusinessLogic
分层开发有时是一种心态。不仅仅是rule1，rule2等。
这不仅仅是为了保护演示文稿中的深层密码
伙伴们。它将代码组织到隔间中以帮助维护和
为了你自己的理智。
即使是我做的最小的网络项目，我也正确地做到了，使用
"文件夹系统"以上。虽然我可以在
次删除业务层对象，但是我不会这样做，我不会这样做。并且每隔一段时间
。你必须添加一些东西，然后你去啊，
的智慧在前面投入良好的业务层。
你可以查看我的博客。
我能给出的另一个提示是：
强类型数据集（对我来说无论如何）是po man''业务
对象/集合。它们适用于小型项目。
最后，如果我知道（曾经）我可能需要2个表示层（一个Web应用程序
和一个winforms应用程序），然后我在前面的单独层中完成所有这些。
" Alan Silver" <人********* @ nospam.thanx.invalid>在消息中写道
news：gj ************** @ nospamthankyou.spam ...
The only thing I do different for "small" versus "enterprise", is that I
sometimes create subfolders instead of actual different assemblies.
http://sholliday.spaces.msn.com/PersonalSpace.aspx 6/5/2006
5/24/2006
(here is example of my tier system)
To contrast "Enterprise" vs "Small App"
Enterprise would be: (for a fictional NorthwindManager application)
GranadaCoder.Applications.NorthwindManager.Present ation.Web.1
GranadaCoder.Applications.NorthwindManager.Present ation.Winforms1
GranadaCoder.Applications.NorthwindManager.Busines sLogic
GranadaCoder.Applications.NorthwindManager.Data
(each of the above would be a seperate assembly)
For a small applications.. I''d have 1 application:
GranadaCoder.Applications.NorthwindManager
and then different folders:
GranadaCoder.Applications.NorthwindManager.Web
GranadaCoder.Applications.NorthwindManager.Biz
GranadaCoder.Applications.NorthwindManager.DAL
You''''ll notice that a few things:
1: I can''t have 2 presentation layers in the small-app method. I can
have 1, because I have to choose Web or Winforms and marry myself to it.
2. Biz contains business objects, logic
3. Data contains objects which return (DataSets, IDataReader''s, Scalars,
and voids/nothings)
The deal is that after doing so many Enterprise applications, I know when
I''m violiating the rules.
Its tempting to throw a business object over to the datalayer at times,
which isnt'' possible in the enterprise setup, because .Data does not
reference .BusinessLogic
Tiered development is a mindset at times. Not just a "rule1, rule2, etc".
It isn''t just about protecting the deep secret code from the presentation
guys. Its organizing code into compartments to help with maintenance and
for your own sanity.
Even the smallest of web project that I do, I do them correctly, using the
"folder system" above. While I ~could remove the business layer object at
times, it just goes so against my grain that I don''t do it. And every once
in a while. you have to add something in and you go "ahh, the wisdom of
putting in the good business layer up front".
You can check my blog.
The other hint I can give is that:
strong typed datasets (to me anyways) is the po man''s business
object/collection. They are fine for small projects.
Finally, if I know (ever) that I might need 2 presentation layers (a web app
and a winforms app), then I do it all in seperate layers up front.
"Alan Silver" <al*********@nospam.thanx.invalid> wrote in message
news:gj**************@nospamthankyou.spam...
你好，
< MSDN（以及其他地方）对于数据访问的方式提供了很多有用的建议，但它们似乎都适用于企业应用程序。也许
我是少数，但我没有那种客户。我的都是小企业，其网站永远不会达到那种规模。我处理那些网站每天可能有几百个访问者（有些甚至没有那么多）并且每天不超过10个订单的企业。
这不是企业级别的不需要编码的重量和企业应用程序所需的层。
我正在寻找小型站点最佳实践指南。我独自工作，并且不太可能改变这一点，因此保护数据库免受编码表示层的人员的额外层和编码的重量是没有必要的。我很高兴将应用程序分成几层，但只有在有一些真正的好处的地方才会这样做。我见过的大多数建议都涉及构建数据访问层，业务逻辑层和表示层。对于由一个人维护的小网站来说，这似乎是最重要的。
到目前为止，我已将.aspx文件视为表示层，
代码隐藏（以及.aspx文件中的客户端验证）作为业务逻辑层，并且在实际与数据库通信的实用程序中具有通用方法。我想知道这是不是很好的做法，或者是否有更好的方法。
我一直在阅读教程
http://www.asp.net/learn/dataaccess/ 他们似乎热衷于使用
Visual Studio中的数据表对象，允许您在不编写代码的情况下创建与数据库的连接。他们还构建了一个逻辑
层，这在我的案例中似乎是不必要的，但我愿意接受教育!!
任何和所有评论都欢迎。请记住，我不是*为企业写作，我正在为小型网站寻找最佳解决方案。
TIA
- Alan Silver
（此行下面添加的任何内容都与我无关）
Hello,
MSDN (amongst other places) is full of helpful advice on ways to do data
access, but they all seem geared to wards enterprise applications. Maybe
I''m in a minority, but I don''t have those sorts of clients. Mine are all
small businesses whose sites will never reach those sorts of scales. I
deal with businesses whose sites get maybe a few hundred visitors per
day (some not even that much) and get no more than ten orders per day.
This is not enterprise level and does not require the weight of coding
and layers that enterprise applications need.
I''m looking for a guide to best practices for small sites. I work alone,
and am unlikely to change that, so the weight of extra layers and coding
to protect a database from the person coding the presentation layer
isn''t necessary. I am happy to split the application into layers, but
only where there is some real benefit. Most advice I have seen involves
building a data access layer, a business logic layer and a presentation
layer. This seems over the top for a small site maintained by one
person.
Up until now, I have treated the .aspx file as the presentation layer,
the code-behind (and the client-side validation in the .aspx file) as
the business logic layer, and have a generic method in a utilities
function that actually communicates with the database. I want to know if
this is good practice, or if there is a better way.
I have been reading the tutorials at
http://www.asp.net/learn/dataaccess/ and they seem keen on using the
Data Table object in Visual Studio that allows you to create a
connection to a database without writing code. They also build a logic
layer, which seems unnecessary in my case, but I am willing to be
educated!!
Any and all comments welcome. Please remember, I am *not* writing for
the enterprise, I am looking for the best solution for small sites.
TIA
--
Alan Silver
(anything added below this line is nothing to do with me)
我同意达伦也。 。如你所愿。
你预付的时间......以后似乎总能得到回报。
Spaghetti代码总是难以维护。
我只做子文件夹...知道我没有违反规则。
如果我不确定那个，那么我会一直坚持使用层级/
单独的层/组件。
" Darren Kopp" <哒******** @ gmail.com>在消息中写道
news：11 ********************** @ m73g2000cwd.googlegr oups.com ...
I agree with Darren also. . as in.
The time you pay up front .. always seems to pay off later.
Spaghetti code is always harder to maintain.
I only do the subfolder thing ... knowing I''m not violating the rules.
If I wasn''t sure about that, then I''d always stick with the tiers as
seperate layers/assemblies.
"Darren Kopp" <da********@gmail.com> wrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...
我发现使用3层
方法构建网站（甚至是小网站）是更多的工作，但它也更容易维护。当你没想到的东西爆炸时，你的代码会更清晰，更容易通过，这有时可以帮助你节省时间而不是花费更长的时间。
我已经做到了两种方式，现在我严格执行3层方法。我是
通常也是唯一的开发人员。那是我的2美分。
-Darren Kopp
I''ve found that building websites (even small ones) with the 3-tier
approach is more work, but it''s a lot easier to maintain as well. Your
code is a lot cleaner and easier to go through when something pop''s up
that you didn''t expect, which can sometimes help you save time rather
than it taking longer.
I''ve done both ways, now i do strictly do the 3-tier approach. I''m
typically the only developer as well. That''s my 2 cents.
-Darren Kopp
这篇关于寻找有关SMALL网站数据访问的最佳实践建议 - 而不是企业的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
