-----------------------------------------------------------
New Message on BDOTNET
-----------------------------------------------------------
From: LovedJohnySmith
Message 2 in Discussion
Deepak:
First isolate your application as follows:
Business Services
Business Components
Business Entities
Business Services
This is the code for the solution, containing constraints to support the
business rules. You may decide to employ some or all of the following:
Business components: used when functionality must be reused over several
business processes or when robust actions and calculations must be performed
against data access and APIs. Business workflows: needed when you are
managing multiple steps and long-running transactions. BizTalk server is the
recommended platform for designing the proper workflow. Business entities:
entities, which represent business concepts, define real life business
relationships and data. Service interface: enables service agents to
access your BSL through a channel such as HTTP or TCP/IP.
Looking at 1,3 and 4 in more detail: Business Components
Business objects should be reused and methods accordingly broken apart whenever
code might prove useful later. Business components can be tightly coupled or
loosely coupled. The loosely coupled effect is achieved when implementing a
workflow or service interface over the BSL. Business components should:
Be invoked by the USL, the service interface or other business services
Be the root of transactions Validate input and output Call the DAL to
perform actions against the database Call external services through service
agents Call other business components and instantiate workflows Raise
an exception to the caller if anything happens in an atomic transaction
Consider whether you require transactional business services. If yes, look at
Enterprise Services and consider the following: Remoting channel
restriction: HTTP and DCOM-RPC are the only channels supported.
Components must be strong named. Components need to be self registering
or a special deployment step needs to be taken. The Enterprise
Services model is available for security, as well as .NET based security.
Business Entities
Business entities are data representations of actual objects in your company.
Typically, entities are representations of your database table structure, but
they do not usually conform to one specific table. Instead, they are
denormalised and represent a small entity schema. Often it is wise to design
your business entities to be stateful objects containing a DataSet or an XML
representation available throughout the object's lifetime.
Business entities should access the database via the DAL, which handles cleanup
and any special auditing features. Business entities are a low level entity
view and are meant to be aggregated to perform specific functions; transactions
are not recommended at this level. Business entity design recommendations
include: Entities should map to data relationships. If a custom entity
is needed, first verify that the data cannot be obtained by aggregating two
entities in the business component member of the BSL. When constructing
business entities, deriving all common logic from a base class is considered
best practice. Maintenance of state should be in DataSets or XML, not
collections or structs. Implement interfaces that expose common
characteristics of all business entities. Business entities should
enforce all constraints and validations needed for a specific entity.
Display validation rules to callers, but do not allow them to change any rules.
A validation rule could be an XSD schema applied to the XML.
An example: business entities for an ecommerce site can consist of Order,
Customer, Product etc. Shopping cart is not a business entity; rather it is a
component because it aggregates the product customer and order entities to
define the cart. Business Service Interfaces
Business service interfaces provide functionality to a remote caller via the
BSL. Because the USL is being bypassed alternative security must be provided
and only the required functionality should be exposed. Design capabilities for
your service interface are: Service interfaces can provide caching, mapping
and schema transformations. Services implementing business logic are not
recommended. Services should be designed with interoperability in mind; so
they should support industry standards and provide the most accepted transfer
method that is sure to be supported in the future. When business
components are deployed on a server separate from the service interface you
might consider giving the service interface its own security policy for
authentication and authorisation. Services can be transactional.
You might consider providing a transparent service so that changes made at the
BSL to business components are automatically available through the service.
Web Services are the most common way to implement a business service interface.
For more information, please have a look at the following site
http://msdn.microsoft.com/architecture/
Thanks,
Smith
http://spaces.msn.com/Johnysmith
-----------------------------------------------------------
To stop getting this e-mail, or change how often it arrives, go to your E-mail
Settings.
http://groups.msn.com/bdotnet/_emailsettings.msnw
Need help? If you've forgotten your password, please go to Passport Member
Services.
http://groups.msn.com/_passportredir.msnw?ppmprop=help
For other questions or feedback, go to our Contact Us page.
http://groups.msn.com/contact
If you do not want to receive future e-mail from this MSN group, or if you
received this message by mistake, please click the "Remove" link below. On the
pre-addressed e-mail message that opens, simply click "Send". Your e-mail
address will be deleted from this group's mailing list.
mailto:[EMAIL PROTECTED]
