Patrick's Blog

Priority Manager–Part 1- Laying out the plan

Now that we have shown the EDMX with XPO/XAF and how use SpecFlow and BDD to run EasyTest scripts, let’s put it all together and show the evolution of a project using all the tools combined.

I have a simple project that I use to track my priorities throughout the day.  It uses some of Stephen Covey’s principles from The 7 Habits of Highly Effective People.  The idea is to write down all your priorities the night before and rank them.  This way when you get started tomorrow you will have your list of priorities.  Now it’s not that new things won’t appear tomorrow and reprioritize your list, but at least now you can track them.  My idea is to create a project that will allow you manage your list from your desktop, a web browser or your mobile device.  This way your list is never too far away.  I will layout the data model and the additional concepts as time progresses.

My goal is to show the power of all of these tools combined and I thought the best way would be to build a project in sequence.  I have had this idea for quite some time so let’s get it completed with the outline below.

Here is the outline of the series of post in the near future:

• Part 2 – Modeling the Business Objects
• Part 3 – Changing XAF Default Properties
• Part 4 – Advanced Settings within Liekhus EDMX/XAF Tool
• Part 5 – Custom Business Rules
• Part 6 – Unit Testing Our Implementation
• Part 7 – Behavior Driven Development (BDD) and SpecFlow Tests
• Part 8 – Using the Windows Application
• Part 9 – Using the Web Application
• Part 10 – Exposing OData from our Project
• Part 11 – Consuming OData with Excel PowerPivot
• Part 12 – Consuming OData with iOS
• Part 13 – Consuming OData with Android
• Part 14 – What’s Next

I hope this helps outline what to expect.  I anticipate that I will have additional topics mixed in there but I plan on getting this outline completed within the next several weeks. 

Thanks

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/cRV

Posted On Sunday, November 20, 2011 10:16 PM | Feedback (0) |

To ORM or Not to ORM. That is the question…

UPDATE:  Thanks for the feedback and comments.  I have adjusted my table below with your recommendations.  I had missed a point or two.

I wanted to do a series on creating an entire project using the EDMX XAF code generation and the SpecFlow BDD Easy Test tools discussed in my earlier posts, but I thought it would be appropriate to start with a simple comparison and reasoning on why I choose to use these tools.

Let’s start by defining the term ORM, or Object-Relational Mapping.  According to Wikipedia it is defined as the following:

Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language.

Why should you care?  Basically it allows you to map your business objects in code to their persistence layer behind them. And better yet, why would you want to do this?  Let me outline it in the following points:

1. Development speed.  No more need to map repetitive tasks query results to object members.  Once the map is created the code is rendered for you.
2. Persistence portability.  The ORM knows how to map SQL specific syntax for the persistence engine you choose.  It does not matter if it is SQL Server, Oracle and another database of your choosing.
3. Standard/Boilerplate code is simplified.  The basic CRUD operations are consistent and case use database metadata for basic operations.

So how does this help?  Well, let’s compare some of the ORM tools that I have used and/or researched.  I have been interested in ORM for some time now.  My ORM of choice for a long time was NHibernate and I still believe it has a strong case in some business situations.  However, you have to take business considerations into account and the law of diminishing returns.  Because of these two factors, my recent activity and experience has been around DevExpress eXpress Persistence Objects (XPO). 

The primary reason for this is because they have the DevExpress eXpress Application Framework (XAF) that sits on top of XPO.  With this added value, the data model can be created (either database first of code first) and the Web and Windows client can be created from these maps.  While out of the box they provide some simple list and detail screens, you can verify easily extend and modify these to your liking.  DevExpress has done a tremendous job of providing enough framework while also staying out of the way when you need to extend it.  This sounds worse than it really is.  What I mean by this is that if you choose to follow DevExpress coding style and recommendations, the hooks and extension points provided allow you to do some pretty heavy lifting while also not worrying about the basics.

I have put together a list of the top features that I have used to compare the limited list of ORM’s that I have exposure with.  Again, the biggest selling point in my opinion is that XPO is just a solid as any of the other ORM’s but with the added layer of XAF they become unstoppable.  And then couple that with the EDMX modeling tools and code generation, it becomes a no brainer.

I have a very small team and limited resources with a lot of responsibilities.  In order to keep up with our customers, we must rely on tools like these.  We use the EDMX tool so that we can create a visual representation of the applications with our customers.  Second, we rely on the code generation so that we can focus on the business problems at hand and not whether a field is mapped correctly.  This keeps us from requiring as many junior level developers on our team. 

I have also worked on multiple teams where they believed in writing their own “framework”.  In my experiences and opinion this is not the route to take unless you have a team dedicated to supporting just the framework.  Each time that I have worked on custom frameworks, the framework eventually becomes old, out dated and full of “performance” enhancements specific to one or two requirements.  With an ORM, there are a lot smarter people than me working on the bigger issue of persistence and performance.  Again, my recommendation would be to use an available framework and get to working on your business domain problems. 

If your coding is not making money for you, why are you working on it?  Do you really need to be writing query to object member code again and again?

Thanks

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/cRU

Posted On Sunday, November 20, 2011 10:00 PM | Feedback (6) |