Hi All,

This is not really an llbl question, but here goes.

I'm going to create a low level dal that goes against a legacy db (Image on an HP3000). I'll be code genning it with MyGeneration. It will just create the db properties and create very simply CRUD operations. The upper level dal will create more normalized objects that can be used in to bl and possibly passed up to the pl. It would be great if those objects would be llbl'ish. Eventually, I'm going to get rid of the legacy stuff and go to sql server.

Any suggestions on how best to structure this so when I do go the llbl that it will be realatively simple on th bl? Should I try to create hiearchial type objects of just flat ones for each table? Not sure how to handle concurrancy issues.

Any, and I mean any, thoughts on this would be appreciated.

Fishy

What about implement (if possible...) a LLBLGenPro Image driver? (sounds dificult? someone did it with FoxPro: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=5657)

What about a Middle Traduction DAL Layer?. You could use LLBLGen ORMSupportClasses (Entity, Collection, Filters, Prefetchpaths, etc.) as your BL-GUI interface and make a traduction at your DAL (uuuffff ). Then when you migrate, at least you have a transparent change to your GUI.

daelmo wrote:

What about implement (if possible...) a LLBLGenPro Image driver? (sounds dificult? someone did it with FoxPro: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=5657)

I don't have an OLEDB for this database, only an ODBC. And even if I did, the database is so ugly, no normalization, string fields that contain COBOL Comp fields , really bad stuff.

daelmo wrote:

What about a Middle Traduction DAL Layer?. You could use LLBLGen ORMSupportClasses (Entity, Collection, Filters, Prefetchpaths, etc.) as your BL-GUI interface and make a traduction at your DAL (uuuffff ). Then when you migrate, at least you have a transparent change to your GUI.

Traduction is that like an Adapter (not data adapter) class to translate llbl enties to something else? I did think about doing that but figured it would be a lot of work as opposed to setting up some simple generic collection objects.

Any more ides? Please bring them on.

Thanks,

Fishy

What about creating a first version of your sql server port, generate a LLBLGen adapter scenario against it, and plug your low level crud to feed your dbgeneric entities? When you're ready for migration, you just need to use the generated adapter instead of your previous dal with the same entities.

Jessynoo wrote:

What about creating a first version of your sql server port, generate a LLBLGen adapter scenario against it, and plug your low level crud to feed your dbgeneric entities? When you're ready for migration, you just need to use the generated adapter instead of your previous dal with the same entities.

That would be my approach too.

Since Image databases work rather different from a RDBMS it will be rather difficult to create a data adapter for it. In my experience, most of the code follows the pattern "fetch enities, do something with it, persist the entities". So, create the llblgen-like entity hierarchy inside a fetch-entities region using the CRUD operations from your lower level dal. The llblgen-like entities need to have some reference back to the lower level Image tables in order to be able to persist the objects later on.

wvnoort wrote:

Jessynoo wrote:

What about creating a first version of your sql server port, generate a LLBLGen adapter scenario against it, and plug your low level crud to feed your dbgeneric entities? When you're ready for migration, you just need to use the generated adapter instead of your previous dal with the same entities.

That would be my approach too.

Since Image databases work rather different from a RDBMS it will be rather difficult to create a data adapter for it. In my experience, most of the code follows the pattern "fetch enities, do something with it, persist the entities". So, create the llblgen-like entity hierarchy inside a fetch-entities region using the CRUD operations from your lower level dal. The llblgen-like entities need to have some reference back to the lower level Image tables in order to be able to persist the objects later on.

So, let me get this straight.

I would create an actual sql server data base that would represent my ideal, noramalized, representation of a Student System (I work for a school district). Then, generate LLBLGen entities . Then, create a Low Level DAL that would perform all of my Image CRUD work . Then, create an Upper Level DAL that would feed the LLBL entities . Then, my BL would take in the LLBL objects and work with them .

Is that correct?

Yep, that's what I'd do I reckon

Or... Frans could simply add HP3000 Image to the list of supported databases . Which, IMHO, would generate mucho bucks. But, since I have already hinted this idea to 'The Great One' (no disrespect intended, you are a genus ), I'm not holding my breath .

Any ideas on how to generically, maybe using MyGeneration or CodeSmith , to somehow ease my work?

Thanks,

Fishy

If I do decide to go the LLBL route, how would I best implement things like predicates and prefetches? Normally, I would put those in the BL. Would I need to write something completly different? Perhaps putting those sort of things in my Upper Level DAL?

Thanks,

Fishy

Well I don't know about Image, but I guess it's all a matter of compromise there.

If you wish to use all of llblgen features, then you'll have to evaluate what costs more: implementing an Image driver/dqe vs actually performing the whole migration to sql server through a dedicated llblgen script.

If both tasks are too heavy, keep with the hybrid solution as suggested, generate the most from what you find for your crud, and provide an abstraction layer leveraging your Image dal. You may inherit DataAccessAdapterBase, while implementing only a subset of the methods, and use projectors to hydrate your entities/collections from the objects returned by your crud layer.

Ah, your saying to use the DataAccessAdapterBase to create my own DataAccessAdapter to go against the Image Database. Correct?

I did not think of that. It does not seem like a simple task. How would the Adapter know how to translate Image datatypes correctly?

Is there documentation for this type detail?

Thanks,

Fishy

Fishy wrote:

Ah, your saying to use the DataAccessAdapterBase to create my own DataAccessAdapter to go against the Image Database. Correct?

I did not think of that. It does not seem like a simple task. How would the Adapter know how to translate Image datatypes correctly?

Creating a DataAccessAdapter would not be my choice. It adds a component with a much higher abstraction level to the solution. I noticed that most of the problems we are experiencing are coming from the high abstraction level components. Also, controlling concurrency, locking and performance with generic components will be hard.

On the other hand, when you are the only developer and you are not afraid of the abstraction of the generic dataaccessAdapter, it makes the actual migration to SqlServer much faster.

If you are willing to invest a little bit, you could also use some additional 3-party components to make things easier. As far as i know there are a number of vendors that have connectivity tools for the image database. An alternative approach can also be to actually persist some of the data to the Sql database and use the SqlServer functionallity to synchronize with image.

Follow this link for an example: http://www.minisoft.com/pages/middleware/odbc32/pages/odbcar.htm

I agree that creating a dataadapter is quite a bit of work

wvnoort wrote:

If you are willing to invest a little bit, you could also use some additional 3-party components to make things easier. As far as i know there are a number of vendors that have connectivity tools for the image database. An alternative approach can also be to actually persist some of the data to the Sql database and use the SqlServer functionallity to synchronize with image.

Follow this link for an example: http://www.minisoft.com/pages/middleware/odbc32/pages/odbcar.htm

I've tested using Linked Servers and found them to be very slow. I currently use Minisoft's odbc driver to communicate with our HP3000 image database. So far, my design looks like this:

SIS LL Dal <---> Raw Image data using ODBC | v SIS UL Dal --> Data objects (generic collections) | v SIS BL (contains methods to request Data objects) | v PL

SIS = Student System.

Do you think I'm on the right track? Any suggestions?

Thanks,

Fishy.

daelmo wrote:

What about implement (if possible...) a LLBLGenPro Image driver? (sounds dificult? someone did it with FoxPro: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=5657)

What about a Middle Traduction DAL Layer?. You could use LLBLGen ORMSupportClasses (Entity, Collection, Filters, Prefetchpaths, etc.) as your BL-GUI interface and make a traduction at your DAL (uuuffff ). Then when you migrate, at least you have a transparent change to your GUI.

I'm beginning to think that this is a good idea.

Instead of creating a driver, couldn't I create a dll that would take in entities and then go to the database using odbc and fill those entities with data. Maybe that would be the same as a driver

Has anybody done this?

Thanks,

Fishy