I am currently running multiple beans from my app which depends on each other, but I want to know if there is any other way where we can make it more generic?
Related
I've asked about how to inject stored procedures support when working with Views in SQL Server.
How to use stored procedures in NHibernate for Create/Update when working with database view
Here's a piece of mapping file:
<sql-insert>
exec sp_cycle_insert ?,?,?
</sql-insert>
<sql-update>
exec sp_cycle_update ?,?,?,?,?,?
</sql-update>
<sql-delete>
raiserror ('Cycle can not be deleted', 10, 1)
</sql-delete>
So, I've done the refactoring, etc, and I run my tests.... All failed.
There reason is that SQL Server has view & stored procedures, whereas every time I run a test I set up database from scratch with:
new SchemaExport(configuration).Execute(false, true, false);
I thought about possible solution and here there are: is there a way to:
run additional scripts (I guess that is the solution) with stuff needed by database (like stored procedures, view etc)
On the other hand, running scripts can fail (currently I use sdf files, but what if I change to different provider in the future?). Also procedures/views use WITH construction as well as some SQL Server 2005 functions that can be not supported by database used during testing.
. So I though that it's time to mock repositories. But also here I see obstacles: views compute some readonly properties and NHibernate accesses backing fields using:
access="nosetter.camelcase"
If I switch to mocking the repository, I would be responsible for implementing view's logic in code. Are there any other solutions? Or I'm in big trouble!?
run additional scripts (I guess that is the solution) with stuff needed by database (likestored procedures, view etc)
Use IAuxiliaryDatabaseObject object(s) for this. It'll contain extra script to run when creating/dropping your schema using SchemaExport. This/these objects you pass in to your NH Configuration object (AddAuxiliaryDatabaseObject).
So I though that it's time to mock repositories. But also here I see obstacles: views compute some readonly properties and NHibernate accesses backing fields using
You should probably do both. Do integration tests against your real database to verify that your infrastructure/DAL/whatever-you-call-it layer works. In higher layers your probably want to write unit tests instead where things like repositories are mocked.
If I understand your question correctly you have problems setting up your test state because some data is private on your entities? That's not really an "issue" caused by NH/repos/data acess, but a general one. There are different ways to solve that, you can; relax your API to make it more testable, have an ctor accepting all data, use reflection one way or the other, let your entity's interface be readonly but its implementation have setters etc etc etc. It's hard to give general recommendation but try to find a way that suits your case.
I've tried reading some previous answers but it's not clear whether or not any of them apply to my situation, as far as I can see. Most of the questions seem to refer to web applications. I figure I'm better off stating my requirements and going from there instead of trying to reverse-engineer advice meant for a different situation. I'm essentially asking two questions:
What does (Fluent) NHibernate support that would, in principle, allow me to achieve the requirements? I'd prefer to use the Fluent API if possible;
What am I going to have to write myself to develop a working solution?
Broadly, the requirements are as follows:
What I'd like to do is use FNH to persist and rehydrate models for a desktop application that would have roughly the same usage model as MS Office, for example - that is, work is kept as self-contained files which are loaded into a local instance of the application.
The current version of the application must be able to import files from all previous versions and preserve all information except that which is declared to the user to be unsupported; by 'import' I mean 'transcribe the model information contained in file A into new file B such that file B is fully compatible with the current version, beside that which is declared to be unsupported.'
The current version of the application must be able to export a current model to be compliant with only the most recent issue of the previous major version of the application. It is not required to supply legacy compatibility with any older revisions of the previous major version.
The nature of the product is such that updates to the file format happen fairly frequently - aim to be able to release to the user every six months or so if necessary as a ballpark figure, and are changed in development much more frequently than that.
I have no objection to writing code to handle this, provided that:
The coding does not take an inordinate amount of time for arbitrarily complicated changes to the schema;
I am able to verify whether or not the translation between versions is complete by calling the FNH API through unit tests;
I can verify that any given model will round-trip correctly between versions and only lose data which is declared to the user to be unsupported between product versions;
So, to summarise:
What, if anything, does Fluent NHibernate supply to enable this kind of use-case?
Can the requirements be readily satisfied as they are, or will I have to make them more specific and constrained?
What should I investigate as to coding myself?
I would suggest using a document database, something like RavenDB, MongoDb etc, for what you are trying to do. I think these would be a better fit than trying to force a RDBMS (sql server, oracle etc) and consequently nHibernate to do something that its not all that good at. not to say that it can't, but you will end up jumping through all sort of hoops to accomplish what you are asking.
One thing to note is that Fluent Nhibernate only puts a Fluent API over the Class Mapping of nhibernate.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
Any anecdotal comments or suggestions are welcome.
We have applications that consume 3rd party vendor data through views. The business has requested that our applications bound to prior versions of the views should be able to continue using them rather than having to sync-up with every updated vendor release of the views. Application "A" should be able to use v.1.1 of the views while application "B" uses v.1.2 of the views, both of which interact with the same tables in the global schema / namespace.
People have recommended naming the views with the release number but that seems cumbersome to applications that do keep in sync with updated releases of the views. Is there a better solution to this problem? Perhaps keeping each supported release of the views in it's own schema and having the views pull from the global schema where the tables are defined and where the data is?
If you are maintaining a view layer, you would normally maintain compatibility between releases by limiting your v1.2 changes to adding additional columns to existing views or adding additional views. Applications that didn't want to upgrade would continue to use the existing columns of the existing views while applications that do want to upgrade could use the new views. The Oracle data dictionary views are a great example of this approach. In every new release, there are dozens of new views that expose new functionality for applications that need it. But scripts that were written against the data dictionary views in Oracle 7 will happily run against an 11.2 database (less efficiently, perhaps).
This is really no different than maintaining any other sort of API. You don't generally take away existing API calls or force users to pass additional parameters to an API when you release the 1.2 version. Instead, you grandfather the old API calls into the new version. From time to time, of course, you may have to deprecate some part of the API and force existing applications to make a small upgrade. But those are relatively rare and require only that the application change the code making that one deprecated call-- the application doesn't need to completely upgrade to the new v1.2 API.
If you're on 11gR2 you should check out Edition-Based Redefinition. It does pretty much what you want, and a whole lot else besides. Find out more.
You could opt to abstract your codes name of the view from the vendors using synonyms for the views, so your app consumes a specific name, whilst the actual view the data is being pulled from changes.
If you want to avoid synonym use, then create your own view selecting from the appropriate view from the vendor, same effect but without synonyms.
You've essentially listed your two feasible options: either name the views with version-specific names or use version-specific schemas. Either way, you'll need to copy off the view definition and recreate it for the version-specific applications.
Assuming that you're truly interested in maintaining a complete copy of the view, this shouldn't be too much of a headache.
We have one vps server, at the moment, and we need to run both test and prod web applications on it. Is it good idea to have one sql instance for production databases and another one for test databases?
Thank you.
I would reckon it's better to have two completely separate instances, yes. At the very least, it would be the first step to hopefully hosting each environment on a different server in the future!
A nice advantage of having completely separate server instances is that it can help avoid (but not prevent, of course) accidentally making mistakes on Production when you think that you're in Test. Since there's that extra step involved of having to explicitly connect to the Production instance hopefully it puts you into the right cautious frame of mind when making changes.
Another possible advantage can be for software that expects databases called particular names, or has accounts with particular names, that may be hard or impossible to change. Having two instances makes it easier for this kind of obstinate software to do its thing rather than having two different environment installations possibly clobbering each other's settings.
What do I need to know when setting up caching using NHibernate, in the case that I have two applications running on different servers, but only one database. Are table dependencies generally sufficient to make sure that weird caching problems don't arise? If so, what sort of polltime should I look at?
well in order for nhibernate to check for concurrency issues you can add a field to your entities. That will cause nhibernate to throw a concurrency exception when trying to update an entity that has been modified by someone else.
If you want to use the second level cache with multiple servers I can recommend a distributed implementation of the nhibernate second level cache, for example NCache:
http://www.alachisoft.com/ncache/nhibernate_index.html