\"dOOdads or EasyObjects?\" That is the question!

[cunharubens]

I want to give mygeneration a try, but I am overwhelmed by all the different architectures.... What are the differences? Benefits? As a starting point:

A - Can someone please help me to understand the differences between dOOdads and EasyObjects? Is there a comparisson chart anywere?

B - Is there a tutorial to build a complete app in C#?

I couldn't find one... If there is one can you point me to it? Could be a simple app with 2 tables. I just want to make sure I am doing things right.

Your help is appreciated.

[mgnoonan]

A) They are similar architectures, since EasyObjects was born from dOOdads, but they do have some differences. The main one is that EO is dependent on Microsoft's Enterprise Library. So if you are using the EntLib, then EO is your only choice. Beyond that, it's up to you to make the decision.

B) There are sample applications included with both downloads, and EasyObjects has some step-by-step examples on the web site. I think there are also some user-supplied videos floating around.

[mike.griffin]

Also, dOOdads is no longer being developed, EntitySpaces has taken it's places, it's not free though.

[cunharubens]

Mike, Matt, Thanks a lot for your replies.

I have spent the weekend reading through the forums of Mygeneration, Doodads, EasyObjects and EntitySpaces and I believe ES is what will meet my needs. I have downloaded a trial version and am playing with it.

However, with ES you guys are talking about a new Architecture Paradigm, not separating BLL from DAL . This seems to come against recommendations from Microsoft and Java. Can you please tell me more about that or point me to more resources where I can research the pros and cons of the ES architectural paradigm?

Once again thanks for your time.

[mike.griffin]

The concept of a DAL is dead, if by DAL you mean having a business object layer than instantiates and creates a DAL layer that it can swap out if one changes databases (which was never basically possible and was never done). With EntitySpaces the same binary can run against any supported database. Business Objects can read and write to the database, code generation changed all that ....

See http://community.entityspaces.net/forum ... /4309.aspx

[dnparsons]

Here is why I believe the BLL/DAL concept is sound in principle, but unworkable for anyone not part of an enterprise development team that codes their own DAL. You've gone to all the trouble to write a DAL that can be swapped out when needed, but all your BLL is written to the API in the DAL. The powers that be say, \"OK we need to switch from SQL Server to MySQL.\" If you've got the developers to make your DAL work with MySQL, using the identical API, you're fine.

But, most of us do not want to hand code our own architecture, when so many proven ones are available. We start with NHibernate, EasyObjects, EntitySpaces, take your pick. If the new back-end isn't supported by your choice, not only do you have to swap out the DAL, but you have to re-write your BLL to conform to the new API. In truth, you are committing yourself to a BLL/DAL combination. Any separation provided by the architecture between BLL and DAL is smoke, if you are not willing to code, test, debug, and maintain a new DAL that conforms to the API used in the BLL. It's called vendor lock-in. And, for small to mid-size development shops, it is serious factor to consider before deciding on an architectural choice.

With code generation, and a well designed architecture, you can gain the benefit of the BLL/DAL principle, without having a strict physical separation of those two tiers. With EntitySpaces, you can swap out back-end databases with a code regen and changing the EntitySpaces provider. Your custom business logic is not touched, even though it is compiled into the same assembly. It is logically separated, not physically separated. In fact, with EntitySpaces, if the db schema are the same, you do not even have to chose one supported db over another. You can read from one and write to the other at runtime. Your presentation layer is of course separate, so that all you have to distribute are the newly compiled MyCompany.BusinessObjects.dll and the EntitySpaces.XxxxxxProvider.dll. But, even here, do not kid yourself. Your presentation layer is written to the API in your BusinessObjects assembly.

So, if you find yourself in a position to have to change vendors, because your current one does not support the newly required database, you are not going to be plopping in a new DAL. It is going to be a major conversion and re-write of the business logic and, probably, the presentation layer as well. You have a devil's choice that only you can answer. What is the likely-hood that a back-end change will force a vendor change? Am I better off coding everything from the get-go so I only have to re-write the DAL? Or, is it more economical to chose an architectural vendor so I can concentrate on business rules and presentation? If the vendor has BLL/DAL separation, is it practical for me to think I am going to write a new DAL, or am I kidding myself? What's more fun, re-writing the same old CRUD routines for a new db's SQL peculiarities, or having the time to get creative with a unique UI?