What is the difference between an Entity Class and an Entity Bean? When I right click on Enterprise Beans in Netbeans 7.4 there is no Entity Bean option as shown below:
I am a .NET Developer. I have spent time Googling but have not found an answer.
To answer the title question:
Entity Bean refer to the EJB Spec 2.x
Entity Class is part of Java Persistence API (JPA) and is a "replacement" for Entity Bean, which are no more part of EJB 3.x, although backward compatibility is guaranteed
Then, related to it:
JPA is the ORM standard since JEE 5, and is basically a standard by Oracle, various vendor provide its concrete implementation (EclipseLink, Hibernate, ecc...). JPA is a specification itself
EJB 2.x the only transaction demarcation allowed is CMT = Container Managed Transaction, which means the app server (container) will manage the rollback if error occurs
CMP is not a replacement for JPA
If you are starting from scratch, maybe for learning purpose, always start with classic stack EJB 3.x (stateless, statefull, message driven, singleton) for business logic and Entity Class for persistence part.
Related
I have been using EF since it first came out. Used to hand build POCOs in 3.5 and was glad to see Self Tracked Entities(STE) in EF4.0.
I have use STEs in a couple of very large projects(500+ entities, some with multiple models). In these projects I use a generic Repository and a generic Unit of Work to persist the entities i.e. 2 small generic classes no mapping. By electing a core entity as the "aggregrate root", other entities are added and updated on the client side and the core entity graph containing these changes is sent to the WCF service and used in the Logic Layer which creates the Repository<[core entity]> and uses the UnitOfWork<[core entity]>.Save(Repository<[core entity]>) to persist the STEs and their children to the database.
Now Microsoft is recommending that we not use STEs. See this article
So my question is, What is(are) the patterns that are now recommended by Microsoft for applications that are persisting client changes to WCF Services that use EF?
I created a EF5 Model and examined the generated code. The there are no attributes for a WCF Service i.e. DataContract, DataMember etc
EF4 had a "ADO.NET DbContext Generator with WCF Support" template, but there isn't a EF5 equivalent.
One site suggested I should use a partial class file and decorate the same properties in that file with these attributes. But unless .net 4.5 has introduced partial properties, I cannot see how that can be done.
Another blog suggested using DTO and Automapper, which means more mapping which is error prone; especially when entity fields change type.
So now that DBContext generated code classes are not Service enabled, does this mean that we need to write another set of classes (POCOs) that:
needs to be mapped FROM the DBContext generated code classes after querying the database.
holds the data state for the WCF Service client(s)
is updatable by that client(s)
is mapped by the client(s)
has the ability to hold changed state so this can be sent back to the WCF Service
needs to be mapped TO the DBContext generated code classes for persistence
It seems we just took a great leap backwards to EF3.
If you code both client and service that runs on your hardware, you don't need to be concerned about data structures at the client as they belong to you.
If you also need to expose some of your service methods to non.NET clients you should do the 5 points above for those services anyway and use DTOs and Automapper in those occasions.These should be in a different WCF Service but implemented against the same Logic Layer, after mapping.
But how many of these type of non.NET client services are be created in the day to day building of web applications in most software teams?
This latest recommendation is confusing as it has not been explained as to WHY STEs are ALWAYS ill-conceived and what now, are the recommended patterns to be used for persisting client changes to WCF Services that use EF.
Can anybody inform me where I can find a good resource that solves this architectural design issue?
P.S.
Please don't recommend WCF Data Services or WCF RIA as we need a lot of control over how your data is retrieved and saved by clients.
Please don't recommend Code First as we use Database First as we want to have and need to control the structure of that database and not have to generated for us.
Ok so i thought the same thing when I first read this article, it seems a bit weird to deprecate a whole branch of EF like this and the intention wasn't terribly well communicated (IMO). I think a couple of things are important here:
STEs as referred to in this article refer to object context based self tracking entities (which act a little like autonomous contexts)
ObjectContext is generally being moved away from in favor of the cleaner DbContext structure (this is for both DB first and Code First)
STEs != DB first generation, you can still use an EDMX model in EF and this isn't likely to change.
When i originally saw this article I mistook STEs for POCO Proxy entities which are still available and AFAIK there are no plans to deprecate. (these achieve a similar technical solution to the problem of change detection but with a nicer interface. Check out this article for the differences EF4: Difference between POCO , Self Tracking Entities , POCO Proxies
So what does this all mean
Basically STEs in terms of the old implementation of a change tracker are being deprecated in favor of the newer forms of change tracking (Snapshot or POCO Proxies). This means that if snapshot tracking doesn't suit you you should look into POCO Proxies which are similar to the old STEs.
You can still use all previous techniques for context generation (DB First, Model First, Code First, and DB-> Code)
How to use (inject) entityManager to Entity Bean?
Inside my Entity bean I have some validations that need to do query on other (unrelated) Entity, some kind of List-Of-Values Entity. What is the right way to do this? To put EntityManager to a constructor of Entity Bean? Or what?
Entity beans do not (in general) support injection of any kind because they are not created by the container.
This general topic was recently discussed on the JSR-338 (JPA 2.1) mailing list and reasons were given why it is generally considered a bad idea for entities to reference entity managers.
Now that I have a good handle on NHibernate 3.2 I now feel ready to use it in anger. What I need now is an ellegant way to inject the mappings I want from an IoC container like castle windsor or the like.
The project that I am working on requires 2 sets of mappings, one to a legacy database that needs to stay put for now and one to the new schema designed to replace the old database at some point in the future. Baring in mind that I am using mapping by code rather than xml mapping.
So at a controller/middle tier level you'd be injecting a repository that implements your ISomethingRepository interface and as a parameter into that repository somehow passing a collection of ClassMapping objects.
Any ideas about the best way to go about this would be appreciated. I'm interested in the general architecture which is why I'm not specifying an IoC container.
Why not have a SessionFactoryFactory which consumes a ConfigurationGenerator.
Due do LinqToSql not being appropriate for Many To Many relationships I am in the process of deciding to move to NHibernate (Fluent NHibernate) unless convinced otherwise...
Project Structure: UI (Mvc2 app with Ninject wiring up all services to controllers, and repositories to services), DomainServiceLayer (all util, helpers, services, domain model etc) and my Repository Layer for persistence. I have a another project call Model which basically exposes the entities, which all projects reference.
Basically I am creating my mappings within the Repository Layer with references to NHIbernate and Fluent NHIibernate, I hope to expose the interfaces to the Domain Service for querying and persisting data. How do I wire up the iSession, where do I wire it up? Any example code, what project should I put it in? Ideally I want to keep this within the Repository Layer... Is it worth learning NHibernate and going through all this?
I recommend looking at the blog posts of Bob. He describes in detail how to use the repository pattern in Ninject using NHibernate. I planned adding an example in the near future to the sample application comming with the MVC exptension as this question comes up again and again.
http://blog.bobcravens.com/2010/06/the-repository-pattern-with-linq-to-fluent-nhibernate-and-mysql/
http://blog.bobcravens.com/2010/07/using-nhibernate-in-asp-net-mvc/
http://blog.bobcravens.com/2010/09/the-repository-pattern-part-2/
Typically I have an NHibernateSessionFactory which is a singleton that has an OpenSession method and I bind ISession typically like this.
Bind<ISession>().ToMethod(context =>
NHibernateSessionFactory.Instance.OpenSession()).InRequestScope();
This method just calls through to ISessionFactory.OpenSession
You can put this into a NinjectModule in your repository layer, which your app can load when it creates the Kernel.
I do the configuration in the Application Layer (i.e. the top layer) as the configuration differs between applications. But it can be useful to break out some of the configuration into classes stored in the Repository Layer.
I open and close the session with an HttpModule.
I've noticed some strange code on a project I am working on - its a SLSB EJB3, and it uses a private instance variable to maintain a cache of data (it even calls it dataCache or something), with a getter/setter. For EJB2 and bellow, this was a typical EJB antipattern - SLSBs are not meant to retain state in between invocations, theres no guarantee you'll see the same data on a subsequent invocation. One of my colleagues said maybe its ok in EJB3 (we don't have much EJB3 experience), but still, its a Stateless Session Bean - why is it trying to maintain state, this doesn't make sense.
Can anyone confirm if this is still a bad idea in EJB3 land, or if somehow it is ok?
Thanks if you can help, Justin
In EJB 3.1 you'd do this cleanly by having a separate singleton bean (with the #Singleton annotation) and injecting via #EJB it into the session beans that need it.
Before EJB 3.1, there is no really clean way and you have to use some sort of hack.
For EJB2 and bellow, this was a typical EJB antipattern - SLSBs are not meant to retain state in between invocations, there's no guarantee you'll see the same data on a subsequent invocation.
This is true and this is somehow a smell (because often wrongly used: people tend to forget that there is no guarantee to get the same instance, that the container could remove some bean from the pool to free resources, that beans could be distributed across JVMs, etc).
One of my colleagues said maybe its OK in EJB3 (we don't have much EJB3 experience), but still, its a Stateless Session Bean - why is it trying to maintain state, this doesn't make sense.
What was true with Stateless Session Beans (SLSB) in EJB 2.x is still true with EJB 3.0, SLSB are still SLSB, EJB 3.0 didn't redefine statelessness.
But if you use an instance variable to hold some read-only resource that is expensive to load (and make sure to load it if null), it should be ok.
Related questions
Stateless and Stateful Enterprise Java Beans
Stateless session bean with instance variables
Static vs Instance members in Stateless EJBs
Why stateless session beans are single threaded?