Soooo, the communication with the payment gateway is complete, which is awesome. That's great, right now I'm mapping imports. Going to be pulling a nightly import from a Apple program from "FileMaker Pro" it's a bit tedious to work with because the imports/exports are not easy to work with. However, the current business runs off it and instead of re-inventing the wheel I'm just adding some rubber and rims to the current one. There are container fields that contain images, now, SQL can hold images, no? I'm pretty sure I remember hearing this and that would be conveinient.
Otherwise I can just store paths to images in the database, which will give me a chance to use LINQ for objects, that will be fun.
Ok, I have a question, I really hope someone out there can help me with this becuase it's something I haven't worked with before. I am working with NHibernate which relies heavily on session. Now, for each data object there is work with the current session. Where should I open -> close that session? On the page level? On the method level? On the application level? If on the application level where would I configure that? web config? app config? how?
I'm getting a realization of exactly how much needs to be done in how much time, I'll be outsourcing some stuff I believe. I have a good friend that does these things.... time for a motivational meeting tomorrow I think.
Happy coding.
Last I used NHibernate, I hid the whole session thing behind a property of a service that was injected to the ones requiring it via Windsor dependency injection. Accesssing the property would check a named thread local to see if a session was there, and if not, it would open a new one and store it in the thread local.
ReplyDeleteI have a feeling that's probably wrong on Bob knows how many counts, but that's what I did nonetheless. :)
SQL Server can hold images directly, and I tend to think that's a much better solution that storing paths to the images. LinqToSql handles the data easily, so I'm sure NHibernate can do the same.
ReplyDeleteThanks guys, I appreciate the feedback.
ReplyDeleteI'm looking into the ayende article on WCF Windsor integration. If anyone has experience working with that I'd love to hear about it.
Sara,
ReplyDeleteLets talk about... Otherwise I can just store paths to images in the database.
Your Pal,
The Big Cheese
For images in SQL server vs. paths-to-files-in-the-filesystem, you want to study up on BLOB support options.
ReplyDeleteAs a suggestion here, ensure that you store the BLOB in a table by itself (or perhaps also with some descriptive metadata) with a FK relation back to the rest of your data. This way, YOU can choose when to query across the JOIN to the table with the BLOB in it to easily avoid returing all those bytes when you don't need them.
Also, if using NHib to access this data this approach will allow lazy-loading of the BLOB data only when you actually attempt to access it whereas if you place it into the main table for your peristed object every time you hydrate those objects from the DB you will be dragging all those bytes across the wire. Since NHib supports lazy-loading for data contained in properties that map to OTHER tables, this approach can allow you to EASILY not retrieve the bytes for all these BLOBs until you really need them (there are other ways to do this too, but building atop the existing support for lazy-loading is by far the simplest).
Best of luck and hope this helps~!
Oh, and for Session lifecycle management on a website, google about session-per-http-request and you will find all kinds of suggestions about best-practices here; the answer that tends to work best is to introduce an HTTPModule that spins up a session instance for each http request so that all work in a single user-request has access to the same session instance.
ReplyDeletei like this article thank you
ReplyDeleteIf anyone has experience working with that I'd love to hear about it.
ReplyDelete