Accessing Data Access Logic Components from the User Interface
Some applications’ user interfaces need to render data that is readily available as
queries exposed by data access logic components. Regardless of whether your user
interface components invoke data access logic components directly, you should not
mix data access logic with business processing logic.
Accessing data access logic components directly from your user interface may seem
to contradict the layering concept. However, it is useful in this case to adopt the
perspective of your application as one homogenous service — you call it, and it’s up
to it to decide what internal components are best suited to respond to a request.
You should allow direct data access logic component access to user interface components
when:
1.) You are willing to tightly couple data access methods and schemas with user
interface semantics. This coupling requires joint maintenance of user interface
changes and schema changes.
2.) Your physical deployment places data access logic components and user interface
components together, allowing you to get data in streaming formats (such as
DataReaders) from data access logic components that can be bound directly to
the output of ASP.NET user interfaces for performance. If you deploy data access
and business process logic on different servers, you cannot take advantage of this
capability. From an operational perspective, allowing direct access to the data
access logic components to take advantage of streaming capabilities means that
you will need to provide access to the database from where the data access logic
components are deployed — possibly including access through firewall ports.
For more information, see Chapter 4, “Physical Deployment and Operational
Requirements.”
bron: http://msdn.microsoft.com...us/dnbda/html/distapp.asp
-----------------------------------------------------------------------
Naar aanleiding van dit hoofdstukje ben ik toch wat in de war. In de basis van N-tier systemen wordt aangeleerd NOOIT vanuit de UI data access componenten aan te roepen. Ook MS heeft in de VB tijd te kennen gegeven dat dit uit den boze zou zijn.
Bespeur ik nu in de .NET architectuur guide dat men zichzelf tegenspreekt om de mensen die DataSets/DataTable objecten koppelen aan een front-end DataGrid een plezier te doen? Is het doorspelen van de call over business logica met de nodige overhead dan alsnog geen beter alternatief? Ik weet dat indien het read-only access betreft het eigenlijk geen kwaad kan, maar toch...
Hoe denken de architectuur goeroe's hierover? Je koppelt indien je het bovenstaande toepast je database scheme nogal hard tegen je UI (wat een nogo is in mijn ogen).
Some applications’ user interfaces need to render data that is readily available as
queries exposed by data access logic components. Regardless of whether your user
interface components invoke data access logic components directly, you should not
mix data access logic with business processing logic.
Accessing data access logic components directly from your user interface may seem
to contradict the layering concept. However, it is useful in this case to adopt the
perspective of your application as one homogenous service — you call it, and it’s up
to it to decide what internal components are best suited to respond to a request.
You should allow direct data access logic component access to user interface components
when:
1.) You are willing to tightly couple data access methods and schemas with user
interface semantics. This coupling requires joint maintenance of user interface
changes and schema changes.
2.) Your physical deployment places data access logic components and user interface
components together, allowing you to get data in streaming formats (such as
DataReaders) from data access logic components that can be bound directly to
the output of ASP.NET user interfaces for performance. If you deploy data access
and business process logic on different servers, you cannot take advantage of this
capability. From an operational perspective, allowing direct access to the data
access logic components to take advantage of streaming capabilities means that
you will need to provide access to the database from where the data access logic
components are deployed — possibly including access through firewall ports.
For more information, see Chapter 4, “Physical Deployment and Operational
Requirements.”
bron: http://msdn.microsoft.com...us/dnbda/html/distapp.asp
-----------------------------------------------------------------------
Naar aanleiding van dit hoofdstukje ben ik toch wat in de war. In de basis van N-tier systemen wordt aangeleerd NOOIT vanuit de UI data access componenten aan te roepen. Ook MS heeft in de VB tijd te kennen gegeven dat dit uit den boze zou zijn.
Bespeur ik nu in de .NET architectuur guide dat men zichzelf tegenspreekt om de mensen die DataSets/DataTable objecten koppelen aan een front-end DataGrid een plezier te doen? Is het doorspelen van de call over business logica met de nodige overhead dan alsnog geen beter alternatief? Ik weet dat indien het read-only access betreft het eigenlijk geen kwaad kan, maar toch...
Hoe denken de architectuur goeroe's hierover? Je koppelt indien je het bovenstaande toepast je database scheme nogal hard tegen je UI (wat een nogo is in mijn ogen).
[ Voor 1% gewijzigd door Scare360 op 24-12-2002 12:09 . Reden: opmaak ]
:strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community)
