The control is just an extended server control class with properties that passes information between the client and logic. The fields are in customizable templates in the client pages. The fields make up a simple form that submits some standard information to the database if it passes some business rules. So anytime you use server controls you never retrieve or store data from the control? You always pass the data back to the client first? Seems like unnecessary repetitive code. The control is merely a subset of the client and it is doing nothing more than the client would. The logic and data access is still broken out into other layers.
On Nov 3, 12:42 pm, Jason Meckley <[email protected]> wrote: > it sounds like you want to build a monolithic component that manages > the entire vertical stack: data access, business logic, presentation, > GUI. I wouldn't do that. as there is little to no room for > adaptability. > > I am suggesting you let each layer manage itself and DRY the visual > controls in this component. you can then build a data access > component, starting with NH, and build out from there. raw ado.net, > linq to sql, EF, LLBL, MS data access block, etc. > > take NH for example. it does one thing really well. Maps a domain to a > database. it's not concerned with presentation, business logic, etc. > it has hooks to tie into other areas. Caching for example. NH has > additional projects to implement caching, NH doesn't do the caching > itself. > > On Nov 3, 12:49 pm, suedeuno <[email protected]> wrote: > > > > > Inline response > > > > No, the client would > > > 1. get the data > > > 2. pass the data to the component. > > > the component will manage how to display the data. as for input, the > > > same is true. you could pull the user input from the component and > > > then do whatever you want to it. > > > Some of the control fields are dropdowns with information like > > countries or other generic information. Still sounds like duplication > > if it will be the same for all uses. This is where the line of DRY and > > YAGNI meet. At this point, the fields are expected to be the same and > > if they're not then there is no point in the control anyway. > > > > > Keep in mind that this control would be accessed from multiple > > > > applications > > > > Even more reason not to tie it to a specific data access methology > > > Not if the fields will be the same regardless of the application. Why > > force every client to access the same data for the control when it can > > be done once within the control. > > > > > and the data would not change for the different > > > > applications. It is standard data not specific to any one application. > > > > Then why is a database needed at all? > > > I meant fields, rather than data. My fault. > > > > > It would seem to me to add quite a bit of duplication to bind the > > > > control from every client if the display data will be basically the > > > > same. > > > > the application using the component is not binding the data. it's only > > > retrieving the data. the component is binding the data (DRY) > > > Yes not binding but accessing which will be repeated across all > > applications that use the control.- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
