network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 10 months |
| seen | Aug 27 '12 at 6:17 | |
| stats | profile views | 11 |
|
Aug 22 |
comment |
Build filter conditions for entities on client side At this point I only need WHERE. What I'm struggling with is to come up with an idea for such a simple object. It would have to represent an expression tree in order to allow for flexible expressions and not just chains of ANDs or the like. Also it should limit client developers to options, which are supported by the server. I don't want somebody to provide a filter on an unindexed column, for example. |
|
Aug 22 |
comment |
Build filter conditions for entities on client side So you wouldn't agree, that building SQL on client side only seems simple in the short run? Apart from the fact that our DBAs would probably lynch me, I'd still have to parse the SQL into some kind of simplified expression tree to present it in the GUI. I agree, that this would simplify serialization and persistence. |
|
Aug 21 |
asked | Build filter conditions for entities on client side |
|
Jul 5 |
revised |
Software Design Idea for multi tier architecture added 245 characters in body |
|
Jul 5 |
answered | Software Design Idea for multi tier architecture |
|
Jul 5 |
comment |
ORM and component-based architecture 0:n? I assume you mean 1:0 (or 1:*). Anyway, thanks for the clarification! |
|
Jul 5 |
comment |
ORM and component-based architecture Thanks for your answer. So you would agree, that in my scenario there should be a 1:n relationship between 1 data access component and n business logic components? |
|
Jul 5 |
awarded | Editor |
|
Jul 5 |
comment |
ORM and component-based architecture Edited question. Sorry if it was too vague. |
|
Jul 5 |
revised |
ORM and component-based architecture Clarification, that my issue is only about the fragmentation of data access, NOT about business logic. |
|
Jul 5 |
comment |
ORM and component-based architecture Thanks for your answer! We already have that intermediate layer on the client side in the form of a service facade, which hides the actual service calls from the ViewModels and builds compound objects where appropriate. But that was not my concern. I feel like we deprive ourselves of the relational capabilities of the ORM by cutting the mappings into different components. So I speculated about an ADDITIONAL data access layer with ORM underneath the business layer. The business layer should absolutely stay separated into various components. Should I edit my question to clarify this more? |
|
Jul 5 |
awarded | Student |
|
Jul 5 |
asked | ORM and component-based architecture |
