Compromise
-
I'm realising that to deliver a better quality end product in better time, sometimes a large compromise in my perfectionism is required. I'm using the DexExpress eXpressApp Framework for an LOB app for a small insurance agency. I've been wrestling with their persistence layer, XPO, for about three days now, logged many questions on their support site, and lost many billable hours. The framework generates a pretty good UI at runtime, and I was trying to use one Person object for policy holder, their spouse, and their children. First up the spouse doesn't need a Spouse screen, children don't need a Children tab, etc. Instead of hours spent generating separate views for all three, I used three different objects. Shoot me. Then, XPO wouldn't let me declare a 1-to-1 association between PolicyHolder and Spouse. It insists that one side of an association must be a list or collection. I went ahead without the association. Shoot me. This app is targeted at a small business, with, I must assume, a very non-technical owner. By no means enterprise stuff. He will never access the DB and add a PolicyHolder with an invalid spouse. If he does, it isn't a train smash and we can assist. On the other hand, my solution has absolute minimum of my code, and therefore minimum risk of post-deployment bugs. He gets a smoothly working app quickly, whereas on other projects I have gone out of my way to be perfect, and written hundreds of lines of code that required extensive beta testing.
-
I'm realising that to deliver a better quality end product in better time, sometimes a large compromise in my perfectionism is required. I'm using the DexExpress eXpressApp Framework for an LOB app for a small insurance agency. I've been wrestling with their persistence layer, XPO, for about three days now, logged many questions on their support site, and lost many billable hours. The framework generates a pretty good UI at runtime, and I was trying to use one Person object for policy holder, their spouse, and their children. First up the spouse doesn't need a Spouse screen, children don't need a Children tab, etc. Instead of hours spent generating separate views for all three, I used three different objects. Shoot me. Then, XPO wouldn't let me declare a 1-to-1 association between PolicyHolder and Spouse. It insists that one side of an association must be a list or collection. I went ahead without the association. Shoot me. This app is targeted at a small business, with, I must assume, a very non-technical owner. By no means enterprise stuff. He will never access the DB and add a PolicyHolder with an invalid spouse. If he does, it isn't a train smash and we can assist. On the other hand, my solution has absolute minimum of my code, and therefore minimum risk of post-deployment bugs. He gets a smoothly working app quickly, whereas on other projects I have gone out of my way to be perfect, and written hundreds of lines of code that required extensive beta testing.
Avoid frameworks at all costs.
-
Avoid frameworks at all costs.
My client insists on it, and he is the one delivering to the business owner. I'll normally avoid frameworks, but the UI on this is excellent, for zero code, well worth using until I develop my own similar components using a simple framework, such as Prism, or other MS application blocks. They aren't half as binding as commercial frameworks.
-
I'm realising that to deliver a better quality end product in better time, sometimes a large compromise in my perfectionism is required. I'm using the DexExpress eXpressApp Framework for an LOB app for a small insurance agency. I've been wrestling with their persistence layer, XPO, for about three days now, logged many questions on their support site, and lost many billable hours. The framework generates a pretty good UI at runtime, and I was trying to use one Person object for policy holder, their spouse, and their children. First up the spouse doesn't need a Spouse screen, children don't need a Children tab, etc. Instead of hours spent generating separate views for all three, I used three different objects. Shoot me. Then, XPO wouldn't let me declare a 1-to-1 association between PolicyHolder and Spouse. It insists that one side of an association must be a list or collection. I went ahead without the association. Shoot me. This app is targeted at a small business, with, I must assume, a very non-technical owner. By no means enterprise stuff. He will never access the DB and add a PolicyHolder with an invalid spouse. If he does, it isn't a train smash and we can assist. On the other hand, my solution has absolute minimum of my code, and therefore minimum risk of post-deployment bugs. He gets a smoothly working app quickly, whereas on other projects I have gone out of my way to be perfect, and written hundreds of lines of code that required extensive beta testing.
Dude just read the XPO documentation and samples separately.Also visit the peer forums and old KB posts.XPO is amazing,compact and can do your job fast.Been using it for over 6 years now.Though not the newer ones.You can't blame it! Would you rather go back and do it without XPO ! Did i hear a NO ?
MetaComic:Daily Comic Viewer & Archiver: >> http://mcdailydilbert.codeplex.com/
-
Dude just read the XPO documentation and samples separately.Also visit the peer forums and old KB posts.XPO is amazing,compact and can do your job fast.Been using it for over 6 years now.Though not the newer ones.You can't blame it! Would you rather go back and do it without XPO ! Did i hear a NO ?
MetaComic:Daily Comic Viewer & Archiver: >> http://mcdailydilbert.codeplex.com/
abmv1 wrote:
Would you rather go back and do it without XPO !
Yes, I'd rather go back and do it with Entity Framework at the back and eXpressApp at the front.
-
abmv1 wrote:
Would you rather go back and do it without XPO !
Yes, I'd rather go back and do it with Entity Framework at the back and eXpressApp at the front.
Holy Crap !
MetaComic Daily Dilbert : http://mcdailydilbert.codeplex.com/
-
Holy Crap !
MetaComic Daily Dilbert : http://mcdailydilbert.codeplex.com/
With EF I can persist any business object, without deriving from any other class, so by business layer is not bound to any framework at all. Tell me you can do that with XPO. Have a look at this Scott Guthrie blog: The above “Dinner” and “RSVP” model classes are “plain old CLR objects” (aka POCO). They do not need to derive from any base classes or implement any interfaces, and the properties they expose are standard .NET data-types. No data persistence attributes or data code has been added to them. Sorry I didn't post the code, but he bloody uses images for his code examples.
modified on Tuesday, February 15, 2011 6:25 AM
-
Avoid frameworks at all costs.
...unless you wrote it yourself :rolleyes:
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
With EF I can persist any business object, without deriving from any other class, so by business layer is not bound to any framework at all. Tell me you can do that with XPO. Have a look at this Scott Guthrie blog: The above “Dinner” and “RSVP” model classes are “plain old CLR objects” (aka POCO). They do not need to derive from any base classes or implement any interfaces, and the properties they expose are standard .NET data-types. No data persistence attributes or data code has been added to them. Sorry I didn't post the code, but he bloody uses images for his code examples.
modified on Tuesday, February 15, 2011 6:25 AM
You can always persist any object anyway you like.If you have agnostic save factory functions etc...I guess your use of XPO was closely bound anyway,delivering working software is your job on time.
MetaComic:Daily Comic Viewer & Archiver: >> http://mcdailydilbert.codeplex.com/
-
You can always persist any object anyway you like.If you have agnostic save factory functions etc...I guess your use of XPO was closely bound anyway,delivering working software is your job on time.
MetaComic:Daily Comic Viewer & Archiver: >> http://mcdailydilbert.codeplex.com/
Yes, true, but my point is you don't need factory functions etc. with EF. And it's free.
-
You can always persist any object anyway you like.If you have agnostic save factory functions etc...I guess your use of XPO was closely bound anyway,delivering working software is your job on time.
MetaComic:Daily Comic Viewer & Archiver: >> http://mcdailydilbert.codeplex.com/
This just in directly from DexEx support: "in XPO, only one-to-many and many-to-may relationships are supported via the Association attribute. One-to-one relationships are considered a specific case and should be implemented as described" blah blah.
-
I'm realising that to deliver a better quality end product in better time, sometimes a large compromise in my perfectionism is required. I'm using the DexExpress eXpressApp Framework for an LOB app for a small insurance agency. I've been wrestling with their persistence layer, XPO, for about three days now, logged many questions on their support site, and lost many billable hours. The framework generates a pretty good UI at runtime, and I was trying to use one Person object for policy holder, their spouse, and their children. First up the spouse doesn't need a Spouse screen, children don't need a Children tab, etc. Instead of hours spent generating separate views for all three, I used three different objects. Shoot me. Then, XPO wouldn't let me declare a 1-to-1 association between PolicyHolder and Spouse. It insists that one side of an association must be a list or collection. I went ahead without the association. Shoot me. This app is targeted at a small business, with, I must assume, a very non-technical owner. By no means enterprise stuff. He will never access the DB and add a PolicyHolder with an invalid spouse. If he does, it isn't a train smash and we can assist. On the other hand, my solution has absolute minimum of my code, and therefore minimum risk of post-deployment bugs. He gets a smoothly working app quickly, whereas on other projects I have gone out of my way to be perfect, and written hundreds of lines of code that required extensive beta testing.
Brady Kelly wrote:
I've been wrestling with their persistence layer, XPO, for about three days now, logged many questions on their support site, and lost many billable hours.
I checked your account and could find only 7 support tickets created by you during one week and half, back in February 2011. My only suggestion for you if you continue to use our products is to contact our Support Team as soon as you experience any difficulty, which was not resolved using the search through online docs, Code Central examples, knowledge base articles, training videos, blogs and finally a large database of support tickets asked by other users.
Brady Kelly wrote:
First up the spouse doesn't need a Spouse screen, children don't need a Children tab, etc. Instead of hours spent generating separate views for all three, I used three different objects. Shoot me. Then, XPO wouldn't let me declare a 1-to-1 association between PolicyHolder and Spouse. It insists that one side of an association must be a list or collection. I went ahead without the association. Shoot me.
I checked a related ticket (http://www.devexpress.com/Support/Center/Issues/ViewIssue.aspx?issueid=Q307810[^]) and think that your task was correctly resolved using the suggestion we provided. Could you please describe in greater detail what was unsatisfactory in it for you? I would love to learn more about your case and help you find an alternative solution, if possible.
Brady Kelly wrote:
This app is targeted at a small business, with, I must assume, a very non-technical owner. By no means enterprise stuff. He will never access the DB and add a PolicyHolder with an invalid spouse. If he does, it isn't a train smash and we can assist. On the other hand, my solution has absolute minimum of my code, and therefore minimum risk of post-deployment bugs. He gets a smoothly working app quickly, whereas on other projects I have gone out of my way to be perfect, and written hundreds of lines of code that required extensive beta testing.
A very fair comment about how much time XAF can save you. Also, both programmers and less-technical or ev
-
With EF I can persist any business object, without deriving from any other class, so by business layer is not bound to any framework at all. Tell me you can do that with XPO. Have a look at this Scott Guthrie blog: The above “Dinner” and “RSVP” model classes are “plain old CLR objects” (aka POCO). They do not need to derive from any base classes or implement any interfaces, and the properties they expose are standard .NET data-types. No data persistence attributes or data code has been added to them. Sorry I didn't post the code, but he bloody uses images for his code examples.
modified on Tuesday, February 15, 2011 6:25 AM
The same is true for XPO :) Just mark your POCO with the PersistentAttribute and that is it.
-
abmv1 wrote:
Would you rather go back and do it without XPO !
Yes, I'd rather go back and do it with Entity Framework at the back and eXpressApp at the front.
Brady Kelly wrote:
abmv1 wrote:
Would you rather go back and do it without XPO !
Yes, I'd rather go back and do it with Entity Framework at the back and eXpressApp at the front.
I believe that when we complete our Domain Components (DC) technology (a part of XAF) and XAF will be fully abstracted from XPO, this scenario can be very easily done. However, with EF you may miss some XAF goodies powered by XPO.