<div mce_keep="true">Business Facade
Provides high level methods that delegate work to other systems. From DoFactory: "Façade defines a higher-level interface that makes the subsystem easier to use"
</div>
<div mce_keep="true">Business Layer
Contains all the business logic for the application, data validation is checked here. E.g. Method for AddProduct(), would call another method from within Business Logic called DoesProductAlreadyExist()
</div>
<div mce_keep="true">Business Objects Domain objects incorporate both behavior and data. e.g. an OrderLineInfo object could have properties for Qty and Price and another property called LineTotal that would compute the Line Total based on the other two properties. This Domain object can
be passed between the DAL and the Business Layer.
</div>
<div mce_keep="true">Data Access Layer
Provides access to data stored, exposes a set of Create,
Remove, Update and Delete methods. Called only from the business Logic layer.</div>
This is how I see each layer working
<div mce_keep="true">My User Interface (Web) calls my
Business Facade with a high level helper method such as CreateOrder()</div>
<div mce_keep="true">The Business Facade then calls the
Business Layer which will go off and create an order, validate all data etc</div>
<div mce_keep="true">The Business Layer calls the Data Access Layer (DAL) to create the order in the database</div>
<div mce_keep="true">The Business Layer returns an onject representation of the order using the an OrderInfo class within the
Business Objects project</div>
<div mce_keep="true">The Business Facade then reutns the order object back to the User Interface (Web)</div>
Does all that sound about right? If so do I put all my caching logic in the
Business Facade or do i create a Caching Layer and how would this fit in with the above 5 steps? I notice in the
Pet Shop.net example they use a CacheDependencyFactory, has any one else used this?
Custom MemberShip Provider I am also implementing a Customer Membership provider and I was going to have the member ship provider call the
Business Facade which in turn would call the Business Layer etc... Is this a good idea or is the Membership provider a kind of
Business Layer in its self and if so should it call the
DAL directly.
I am pretty sure for what I need to do this is what I need but I just wanted to see if others have used the same approach to projects and to see if I have the definitions for all the layers correct!
I think your better off building up a simple test case, using your assemblies and figure what you need as you go - (however, a design or plan to work to is much needed and worth the time spent on it) it all depends I guess on what kind of context your developing
in. Are you on a timeframe, can you afford to experiment, if so then go for it, otherwise, while your waiting for an answer, I suggest you examine your brief or spec and break down exactly what your solution has to do, why, when and how etc...list the critical
tasks and for each task, look at the implications or possible weaknesses you need to cover.
Caching is important, but I would imagine this is already well catered for in the web framework your using.
I always find its best to learn first hand, take advice sure, but always give it a good go first. This might seem like I am teaching you to suck eggs, I am not, but its the only advice I can give.
Look closely at your requirements first, following a pattern or example is fine, but your own design should be more important...then again I could be wrong!...
Your project looks fine, but if you get the opportunity, make a copy of it and run through a common process start to finish and see where you get to...when u hit a wall - shout.
If I were the one designing I would remove the Facade because I think the application is simple from the way you presented it. The only use of the Facade is to encapsulate your business layer anyway so removing it will minimize "code bloat" -- but I might
be wrong.[:)]
Regards,
Chris Adrian S. Ongsuco
URL: http://www.chrisongsuco.net
Yeah I see what you mean, I could remove the Facade layer and just protect all methods that were used only in the Business Layer and that have no meaning to the UI, meaning that only the helper type methods are exposed to the UI layer. e.g.
I could have a public method call createUser() and then have some
protected methods like checkIfUserAlreadyExists() that are only called by other methods in the class.
scott@elband...
Star
11346 Points
1865 Posts
Layered Architecture WorkFlow :: Business Facade - Business Layer - Business Objects - DAL?
Aug 10, 2007 10:05 AM|LINK
Hello,
I have laid out my application as below:
As my understanding goes:
Provides high level methods that delegate work to other systems. From DoFactory: "Façade defines a higher-level interface that makes the subsystem easier to use"
</div>
Contains all the business logic for the application, data validation is checked here. E.g. Method for AddProduct(), would call another method from within Business Logic called DoesProductAlreadyExist()
</div>
Domain objects incorporate both behavior and data. e.g. an OrderLineInfo object could have properties for Qty and Price and another property called LineTotal that would compute the Line Total based on the other two properties. This Domain object can be passed between the DAL and the Business Layer.
</div>
Provides access to data stored, exposes a set of Create, Remove, Update and Delete methods. Called only from the business Logic layer.</div>
This is how I see each layer working
Does all that sound about right? If so do I put all my caching logic in the Business Facade or do i create a Caching Layer and how would this fit in with the above 5 steps? I notice in the Pet Shop.net example they use a CacheDependencyFactory, has any one else used this?
Custom MemberShip Provider
I am also implementing a Customer Membership provider and I was going to have the member ship provider call the Business Facade which in turn would call the Business Layer etc... Is this a good idea or is the Membership provider a kind of Business Layer in its self and if so should it call the DAL directly.
I am pretty sure for what I need to do this is what I need but I just wanted to see if others have used the same approach to projects and to see if I have the definitions for all the layers correct!
Any comments would be appreciated.
Thanks
Scott
design pattern business bll dal Class Design OOP caching Petshop ASP.NET Architecture architecture Patterns & Practices Workflow N-Tier business logic layer FACADE Architecture Best Practices 3-tier programming 3-Tier Architecture ntier 3tier layered architecture data access layer custom membership role provider
scott@elband...
Star
11346 Points
1865 Posts
Re: Layered Architecture WorkFlow :: Business Facade - Business Layer - Business Objects - DAL?
Aug 17, 2007 08:50 AM|LINK
StevenPaul
Member
350 Points
73 Posts
Re: Layered Architecture WorkFlow :: Business Facade - Business Layer - Business Objects - DAL?
Aug 17, 2007 09:05 AM|LINK
I think your better off building up a simple test case, using your assemblies and figure what you need as you go - (however, a design or plan to work to is much needed and worth the time spent on it) it all depends I guess on what kind of context your developing in. Are you on a timeframe, can you afford to experiment, if so then go for it, otherwise, while your waiting for an answer, I suggest you examine your brief or spec and break down exactly what your solution has to do, why, when and how etc...list the critical tasks and for each task, look at the implications or possible weaknesses you need to cover.
Caching is important, but I would imagine this is already well catered for in the web framework your using.
I always find its best to learn first hand, take advice sure, but always give it a good go first. This might seem like I am teaching you to suck eggs, I am not, but its the only advice I can give.
Look closely at your requirements first, following a pattern or example is fine, but your own design should be more important...then again I could be wrong!...
Your project looks fine, but if you get the opportunity, make a copy of it and run through a common process start to finish and see where you get to...when u hit a wall - shout.
ChrisOngsuco
Member
319 Points
66 Posts
Re: Layered Architecture WorkFlow :: Business Facade - Business Layer - Business Objects - DAL?
Aug 21, 2007 10:58 AM|LINK
If I were the one designing I would remove the Facade because I think the application is simple from the way you presented it. The only use of the Facade is to encapsulate your business layer anyway so removing it will minimize "code bloat" -- but I might be wrong.[:)]
Chris Adrian S. Ongsuco
URL: http://www.chrisongsuco.net
scott@elband...
Star
11346 Points
1865 Posts
Re: Layered Architecture WorkFlow :: Business Facade - Business Layer - Business Objects - DAL?
Aug 21, 2007 11:23 AM|LINK
Yeah I see what you mean, I could remove the Facade layer and just protect all methods that were used only in the Business Layer and that have no meaning to the UI, meaning that only the helper type methods are exposed to the UI layer. e.g.
I could have a public method call createUser() and then have some protected methods like checkIfUserAlreadyExists() that are only called by other methods in the class.
Is that what you mean?
ChrisOngsuco
Member
319 Points
66 Posts
Re: Layered Architecture WorkFlow :: Business Facade - Business Layer - Business Objects - DAL?
Aug 22, 2007 05:03 AM|LINK
Yes.
Chris Adrian S. Ongsuco
URL: http://www.chrisongsuco.net