|
|
You're in the
dotnet distributed apps
group:Business Entity Designs
dotnet distributed apps:
Hi,
I'm currently designing a large order system implementing a distributed n-tier design with typed datasets (its quite similar to the Duwamish sample). I will be designing entities for my core operations such as orders, products etc - each of these will be encapsulated within their own classes. The client GUI (WinForms) will need to be able to search and sort the data on various screens throughout the application. For example, to search for orders the user will have a number of combo boxes which they can select some or all criteria to apply to a search & the combos need to be populated from tables on a SQL 2000 database. There are quite a few options, such as 'Status Code', 'Financial Period' etc etc. I do not need any CRUD methods for this data, its all maintained by the SQL database itself rather than through user interaction. My question is - how should I design this simply for populating combos on the client? I want to encapsulate the entities, but I don't want to get into the position where I'm mapping out typed datasets for every table needed for combo box selection. I have a number of layers in my Business Facade which take care of product and order data, should I just add another layer in for 'Miscellaneous Read Only Data' which can then pass back standard datasets? I'm unsure on what the best design practice is for this sort of information in a distributed scenario - any advice appreciated. Thanks
What about a "LookupData" class - either custom class that returns
Hashtables for various lookup data, or a typedataset with DataTable representations of the lookup data? class LookupData { public static Hashtable GetStatusCodes() public static Hashtable GetFinancialPeriods() } or usage of a typed dataset: cboStatusCodes.DataSource = lookupDataSet.StatusCodes.DefaultView; cboFinancialPeriods.DataSource = lookupDataSet.FinancialPeriods.DefaultView; - Ron [quoted text, click to view] "DylanM" <DylanM@discussions.microsoft.com> wrote in message news:B8DA8234-A15E-4B83-A20A-AF334390F724@microsoft.com... > Hi, > > I'm currently designing a large order system implementing a distributed > n-tier design with typed datasets (its quite similar to the Duwamish > sample). > I will be designing entities for my core operations such as orders, > products > etc - each of these will be encapsulated within their own classes. > > The client GUI (WinForms) will need to be able to search and sort the data > on various screens throughout the application. For example, to search for > orders the user will have a number of combo boxes which they can select > some > or all criteria to apply to a search & the combos need to be populated > from > tables on a SQL 2000 database. There are quite a few options, such as > 'Status > Code', 'Financial Period' etc etc. I do not need any CRUD methods for this > data, its all maintained by the SQL database itself rather than through > user > interaction. > > My question is - how should I design this simply for populating combos on > the client? I want to encapsulate the entities, but I don't want to get > into > the position where I'm mapping out typed datasets for every table needed > for > combo box selection. I have a number of layers in my Business Facade which > take care of product and order data, should I just add another layer in > for > 'Miscellaneous Read Only Data' which can then pass back standard datasets? > > I'm unsure on what the best design practice is for this sort of > information > in a distributed scenario - any advice appreciated. > > Thanks > Dylan
Ron - thanks for reply.
That's kind of what I was thinking - even though this data isn't really related, just group it all together since it's all used for a similar purpose. In terms of my Facade level, i've mapped out a number of systems (again, quite similar to Duwamish). I have an OrderSystem, ProductSystem, BuyingSystem etc. So just add in another system - LookupSystem - that provides a simple interface to the LookupClass in the DAL - sound good?! Thanks [quoted text, click to view] "RYoung" wrote:
> What about a "LookupData" class - either custom class that returns > Hashtables for various lookup data, or a typedataset with DataTable > representations of the lookup data? > > class LookupData > { > public static Hashtable GetStatusCodes() > public static Hashtable GetFinancialPeriods() > } > > or usage of a typed dataset: > cboStatusCodes.DataSource = lookupDataSet.StatusCodes.DefaultView; > cboFinancialPeriods.DataSource = lookupDataSet.FinancialPeriods.DefaultView; > > - Ron
Yeah, no sense in complicating something that needs a fast response time,
and doesnt' change often (such as lookup data). The solutions of systems you propose leans towards SOA, which I'm really starting to like in that the components, or systems in this case, are self-describing and by that fact makes the end-user/developer confident that the component itself is truly a system in every sense of the word - and of course, a system of systems leads to an application (if the systems are thier own assemblies). For instance, if I were building some kind of price-comparison agent for books, I would reference your ProductSystem and the Amazon web service to build my price-bot. By the way, can you provide some more info on the logical structure of your application? Mostly the assemblies and what their responsibilities are? I'm just curious on that, it can be a mind-boggling thought experiment at times. - Ron [quoted text, click to view] "DylanM" <DylanM@discussions.microsoft.com> wrote in message news:89B6E282-5248-4199-A5E4-6172B0E8A810@microsoft.com... > Ron - thanks for reply. > > That's kind of what I was thinking - even though this data isn't really > related, just group it all together since it's all used for a similar > purpose. > > In terms of my Facade level, i've mapped out a number of systems (again, > quite similar to Duwamish). I have an OrderSystem, ProductSystem, > BuyingSystem etc. So just add in another system - LookupSystem - that > provides a simple interface to the LookupClass in the DAL - sound good?! > > Thanks > > > "RYoung" wrote: > >> What about a "LookupData" class - either custom class that returns >> Hashtables for various lookup data, or a typedataset with DataTable >> representations of the lookup data? >> >> class LookupData >> { >> public static Hashtable GetStatusCodes() >> public static Hashtable GetFinancialPeriods() >> } >> >> or usage of a typed dataset: >> cboStatusCodes.DataSource = lookupDataSet.StatusCodes.DefaultView; >> cboFinancialPeriods.DataSource = >> lookupDataSet.FinancialPeriods.DefaultView; >> >> - Ron >
Thanks again...
Sure - i'm still at UML stage since this is going to be a very large system & I'm trying to cover everything before I write any code (lessons learnt from past experience!). Quick summary - the key functionality. This is going to be an order system for a retail company. It will basically allow buyers to select a product from a catalogue system (based on an existing in-house developed IBM DB2 solution), then place orders for all the stores in the company - allocating quantities to each store based on the local market strength in the genre of the product. Tier Roles and Responsibilities (6 assemblies in total) Client user interaction via GUI Invoking remote calls to the Business Façade All business and application logic serviced by .NET remote \ COM+ Assemblies Business Facade Simplified interfaces into the lower level tiers. Product System (retrieves product details from catalogue system) Order System (allocates order quantities, places orders, uses data from Product System) etc Business Rules Validates and ensures data integrity Accesses data services Contains application specific data Data Access Specific extended DataSet classes that represent the underlying data tiers Retrieve catalogue product information Supply relevant on-hand and sales data Interact with DB2 servers for store dial ins & order amendments Save orders and quantities in SQL Server database. Common Defines application configuration settings and shapes datasets Framework Low level system functionality, provides a consistent approach on handling error scenarios. Tracing and logging support, error checking and automatic logging of asserts and conditional checks. I'm trying to completely abstract the GUI from the database, it simply has to make calls into the Business Facade to accomplish any tasks. The GUI only references the Facade and the Common assemblies, so any changes in the actual underlying schema's should only need to be updated in these DLL's. I'm implementing this in WinForms, but I think they'll be wanting a simplified web front end of some sort as well - so this approach should allow easy future development and extensibility. I've tried to look at existing systems & examples (hence my Duwamish references!) for implementing the best solution. Any thoughts appreciated - I think I'm getting there now though - my 50 page FSD is a monster, but proving a worthwhile reference! Thanks Dylan [quoted text, click to view] "RYoung" wrote:
> By the way, can you provide some more info on the logical structure of your > application? Mostly the assemblies and what their responsibilities are? I'm > just curious on that, it can be a mind-boggling thought experiment at times. > > - Ron >
Yeah, gotta love the typed datasets, drag & drop stuff....then a bit of
customisation...too easy...& a nice visual representation of your ds. Cheers for the IssueVision pointer, I'll have a look at that to see if there are any other bits I can *borrow*! [quoted text, click to view] "RYoung" wrote:
> I always like Duwamish. I always wondered why they never generated a typed > dataset. Are you following that route as well for your datasets? But, in a > web app, there is no dire need to call for child rows on a parent datarow > when there is no in-memory dataset as in a WinForm app. > > IssueVision (windowsforms.net applications section) is a good example of > using delegates to keep different views of a dataset in sync if you want to > check that out for your GUI. > > Ron >
I always like Duwamish. I always wondered why they never generated a typed
dataset. Are you following that route as well for your datasets? But, in a web app, there is no dire need to call for child rows on a parent datarow when there is no in-memory dataset as in a WinForm app. IssueVision (windowsforms.net applications section) is a good example of using delegates to keep different views of a dataset in sync if you want to check that out for your GUI. Ron [quoted text, click to view] "DylanM" <DylanM@discussions.microsoft.com> wrote in message news:4F1239C3-4B21-40C1-8569-013BEB84B49D@microsoft.com... > Thanks again... > > Sure - i'm still at UML stage since this is going to be a very large > system > & I'm trying to cover everything before I write any code (lessons learnt > from > past experience!). > > Quick summary - the key functionality. > This is going to be an order system for a retail company. It will > basically > allow buyers to select a product from a catalogue system (based on an > existing in-house developed IBM DB2 solution), then place orders for all > the > stores in the company - allocating quantities to each store based on the > local market strength in the genre of the product. > > Tier Roles and Responsibilities (6 assemblies in total) > > Client user interaction via GUI > Invoking remote calls to the Business Façade > All business and application logic serviced by .NET remote \ COM+ > Assemblies > > Business Facade > Simplified interfaces into the lower level tiers. > Product System (retrieves product details from catalogue system) > Order System (allocates order quantities, places orders, uses data from > Product System) > etc > > Business Rules > Validates and ensures data integrity > Accesses data services > Contains application specific data > > Data Access > Specific extended DataSet classes that represent the underlying data tiers > Retrieve catalogue product information > Supply relevant on-hand and sales data > Interact with DB2 servers for store dial ins & order amendments > Save orders and quantities in SQL Server database. > > Common > Defines application configuration settings and shapes datasets > > Framework > Low level system functionality, provides a consistent approach on handling > error scenarios. > Tracing and logging support, error checking and automatic logging of > asserts > and conditional checks. > > I'm trying to completely abstract the GUI from the database, it simply has > to make calls into the Business Facade to accomplish any tasks. The GUI > only > references the Facade and the Common assemblies, so any changes in the > actual > underlying schema's should only need to be updated in these DLL's. > > I'm implementing this in WinForms, but I think they'll be wanting a > simplified web front end of some sort as well - so this approach should > allow > easy future development and extensibility. > > I've tried to look at existing systems & examples (hence my Duwamish > references!) for implementing the best solution. > > Any thoughts appreciated - I think I'm getting there now though - my 50 > page > FSD is a monster, but proving a worthwhile reference! > > Thanks > Dylan > > > > "RYoung" wrote: > >> By the way, can you provide some more info on the logical structure of >> your >> application? Mostly the assemblies and what their responsibilities are? >> I'm >> just curious on that, it can be a mind-boggling thought experiment at >> times. >> >> - Ron >> >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |