.NET - по сравнению с EJB

Можно легко поспорить Spring.NET ...

Spring становится нормой в Java, либо в дополнение к JavaEE / EJB, либо полностью заменяет его. Многие концепции Spring очень похожи на JavaEE / EJB, но просто лучше. Spring.NET, очевидно, является реализацией .NET.

Кроме этого, я не мог предложить ничего другого, так как я не использовал активно .NET в течение многих лет ...

большая часть функций EJB уже встроена в .net (т.е. транзакция базы данных), но есть пространство имен корпоративных сервисов, которое также предоставляет множество функций.

Определение терминов важно

При проведении сравнений важно определение терминов. EJB - это компонентная модель. Он определяет постоянство, транзакцию, удаленное взаимодействие, активацию и возможности безопасности (и, возможно, другие) для компонентов, которые работают в the container.

You can look at comparable technologies in .NET, if that is what you are after - the technical capabilities of the component model.

On the other hand some people use "EJB" as a term to loosely refer to J2EE (or Java EE?). In which case it refers not just to a component model, but to a set of related Java technologies usually associated to server-side applications, including a component model. This might even include toolsets, which of course are only tangentially related to the component model. If that is the comparison, then it is more aptly described as "J2EE vs. .NET".

Still other people might be using an even fuzzier definition for EJB to include things like web services capability, REST/XML communications, or другие вещи, которые строго выходят за рамки Java EE или EJB. Другими словами, когда они говорят «сравните EJB с .NET», они в действительности имеют в виду сравнение «серверных платформ Java с серверными .NET». Последнее кажется мне гораздо более практичным для сравнения, чем, скажем, сравнение компонентных моделей.

При сравнении важно четко понимать, что сравнивается.

EJB - компонентная модель

В EJB вы определяете объект и помечаете его как Session Bean или Entity Фасоль. Также есть последнее добавление Message Driven Bean. Три ароматы компонента в EJB. Сессионный компонент получает активацию - как это сделать запускается и, возможно, «пассивируется» во времена высоких ресурсов конфликт на сервере / контейнере. SB также получает безопасность и remoting services.

The basic idea is to define an object and then attach attributes to it, either through the deployment descriptor or through in-code attributes, the analog for which is called annotations in Java.

The closest thing to a EJB Session Bean is a .NET object. In any .NET application, you can mark an object with transaction attributes, just like a EJB SB. You can make it remotable, if you like, with .NET Remoting and more attributes. Outside of COM+, there is no passivation technology in .NET; .NET just ignores pooling as a generally interesting thing to do with in-memory objects, and as a result there's no approach to do activation/passivation in .NET as there is with EJB.

sidebar #1: that isn't quite true. In .NET, the Workflow capability provides a facility to have long-running activities that can and will be passivated and re-activated. But, Workflow is a distinct metaphor from "server side objects" or "services" which is the centerpoint of most server-side application architectures that use .NET.

sidebar #2: It used to be that the designers of server-side platforms thought everyone was gonna want to use object pooling in order to be more efficient. Now it turns out that the JVM and .NET CLR are fast enough at creating objects, and memory is plentiful enough, that in general, object pooling is not of practical use. It is no longer interesting for the general case, though it still pays good dividends for expensive objects like database connections.

As with EJB, in .NET you can attach security атрибуты объекта, чтобы разрешить ему запускаться или не запускаться в зависимости от личность звонящего или другое "доказательство".

Бобы сущности - другое животное. Хотя настойчивость и удаленность могут в большинстве практических руководств рекомендуется, чтобы entity-компонент не предоставляет удаленный интерфейс. Вместо этого рекомендация призывает к сессионный компонент для вызова объектного компонента. Итак, давайте просто рассмотрим EB как постоянные объекты.

В .NET есть множество альтернатив. LINQ-to-SQL дает один вариант - с ORM и сервисами сохранения. Сущность ADO.NET Framework - возможно, более сопоставимая технология. Конечно все остальные услуги в .NET - безопасность транзакций, удаленное взаимодействие и т. д. - также могут быть применяется к объектам, использующим ADO.NET Entity Framework или LINQ.

С другой стороны, в зависимости от того, где вы делаете упор в EJB umbrella, there may be better comparables. If you primarily use EJB for remoting - and with the advent of REST, SOAP and other lightweight protocols, almost no one does this anymore as far as I can tell - then a better comparable in .NET is WCF.

Finally, the comparable to EJB MDB are .NET Queued Components.

EJB Remoting

There are some common aspects to all these types of EJBs - like remote interfaces. Actually most architects recommend that you don't distribute your EJBs. In other words, they discourage people from using the remoting aspect that is so commonly discussed. Instead a servlet should invoke an EJB that is local, rather than invoking one on a remote machine. This is Fowler's First Law: Don't distribute your objects.

On the other hand, sometimes you must.
WCF is the communications framework within .NET, and is the aspect in .NET most comparable to EJB remoting. But they are not equivalent. WCF is a very general purpose framework for remote communications, supporting sync and async, multiple protocols, and extensible transport and channel model, while EJB remoting is fairly limited.

Is starting from EJB the right approach?

EJB doesn't say anything (as far as I know) about web services, or REST, or management or lightweight frameworks, or even HTML, or developer tools. Starting a comparison with "EJB vs blank" artificially constrains the discussion a little bit. It frames the discussion in a way that may not be optimal.

There's nothing in EJB to handle, for example, an HTML page metaphor. You get that in servlets or one of its cousins (portlets, etc), some of which are in J2EE proper. But strictly speaking, HTML output isn't covered in EJB.

Now, maybe you intend one of the more expansive definitions of EJB. To that end, J2EE has now added web services into the specification. But even so, I'm not sure how relevant it is to consider the spec, with the variety of add-on Java-based frameworks for SOAP web services and REST.

Likewise, if you want to consider UI capabilities like portlets, servlets, and AJAX and compare them to the .NET equivalents, then you've moved well beyond EJB and J2EE and into server-side Java in general.

It gets back to my earlier point - be clear and precise in your own mind about what you are interested in examining or comparing.

The EJB and J2EE specifications were ambitious - attempting to define the frameworks for server-side applications. But there was always a time lag between what developers were doing, what the spec was saying, and what the vendors were delivering. You know, maybe there was a 1-year lag between the finalization of a new version of the J2EE spec and the release of a compliant server from IBM.

Because of this it ended up being sort of artificial, after-the-fact. The spec was describing things that people were already doing. Things like Spring were coming out and J2EE wasn't saying anything about them. For the longest time J2EE had nothing to say about REST or Web services or AJAX. (Even now, does it say anything about AJAX? I don't know.)

In light of the distance between the theory of the spec and the reality of actual practice by developers, a better approach might be to identify the application requirements, and затем сравните уместность EJB и других связанных технологий с приложения, которые вы хотите создать.

Другими словами - предположим, что одним из ваших требований является то, что приложение будет доставляться через браузер, и оно будет реагировать на запросы AJAX. В этом случае вам придется рассмотреть jQuery, а это нигде не рассматривается в J2EE или EJB. Фреймворки AJAX доступны в различных продуктах (как Java, так и .NET). Например, Visual Studio использует jQuery для материалов ASPNET AJAX. Но, придерживаясь спецификаций, мы упускаем из виду это.

Bottom Line

Суть в том, что любое приложение, которое вы создаете с EJB, можно встроить в .NET, и наоборот.

Я думаю, что сравнение типа «EJB vs .NET» может быть интересно как академический обсуждение, но если вы хотите получить практическое представление о том, какую технологию use where, then you need to think a little differently.

You need to identify and prioritize requirements - like speed of development, cost of deployment, mechanism of deployment, tool support, deployment platform support, language support, performance, UI appearance, UI options, etc. Then weigh the options against that prioritized list.