Please explain the concept of Application Module(AM) that is present in Oracle ADF framework.
If we divide a normal Java EE application into MVC layers, then which layer does the AM fall into? What facilities does it provide and how does it fit itself in respect to other components of the ADF framework?
If you were to talk in "regular" Java EE concept and do a parallel to JPA/EJB architecture then the AM is basically your EJB Session facade.
It handles resource pooling and transactions, and it contains the data model (VOs=named queries) that is used by the clients.
If we divide a normal Java EE application into MVC layers, then which layer does the AM fall into
The Application Module is part of the Model (M) layer.
What facilities does it provide and how does it fit itself in respect to other components of the ADF framework
The Application Model defines the data model for the binding layer. It contains View object and View link definitions which basically correspond to database queries.
Application Modules can also be nested, and the root application module also provides the transaction boundary for the application. The associated Transaction object can be retrieved with a call to getTransaction().
Related
We have a mobile application made in VB.NET for Windows CE/Mobile smart devices for shipping/reception operations in a warehouse. This application connects to a SQL Server and extensively uses stored procedures. Since Windows Mobile devices are discontinued and replaced by Android devices, we have to convert our solution to Android, using Visual Studio's Xamarin and C#.
I'm a newbie at Android programming. Is there a way we can connect directly to a SQL Server instance and call a stored procedure from Android? I made some searches and people says it's better to call web services as an intermediary between Android and SQL Server. Is it the best practice?
Thanks for your insight and help
Upgrading Legacy applications can be incredibly complicated depending on the technology and frameworks used.
The first thing I would suggest taking a look at is the Architecture documentation Microsoft produced for Xamarin and Cross-platform frameworks which you can see here
Typical Application Layers
Data Layer – Non-volatile data persistence, likely to be an SQLite database but could be implemented with XML files or any other suitable
mechanism.
Data Access Layer – Wrapper around the Data Layer that provides Create, Read, Update, Delete (CRUD) access to the data without
exposing implementation details to the caller. For example, the DAL
may contain SQL statements to query or update the data but the
referencing code would not need to know this.
Business Layer – (sometimes called the Business Logic Layer or BLL) contains business entity definitions (the Model) and business logic.
Candidate for Business Façade pattern.
Service Access Layer – Used to access services in the cloud: from complex web services (REST, JSON, WCF) to simple retrieval of data and
images from remote servers. Encapsulates the networking behavior and
provides a simple API to be consumed by the Application and UI layers.
Application Layer – Code that’s typically platform specific (not generally shared across platforms) or code that is specific to the
application (not generally reusable). A good test of whether to place
code in the Application Layer versus the UI Layer is (a) to determine
whether the class has any actual display controls or (b) whether it
could be shared between multiple screens or devices (eg. iPhone and
iPad).
User Interface (UI) Layer – The user-facing layer, contains screens, widgets and the controllers that manage them.
Now you could just simply use the System.Data.SqlClient assembly and fire off stored procedure runs against your database. However a more common approach would to create an REST Api that sits in-between your client and your back-end services.
You can download a handy E-book created by the Devs over at microsoft that will show you some common enterprise patterns to use for Cross-platform technologies like Xamarin which can be found here
Here's one such example of the kind of patterns those links refer to.
You can also find an overview of various web services that you can use at this link
The options it gives you an overview of are:
ASMX
WCF
REST
So plenty of choice, but depends on your current approach.
I am new to ADF and come from a .Net background. My goal is to move towards a DDD for my application so that the code is encapsulated and represents my business processes. That plan pushes me towards using CQRS to separate my Domain Models/Commands with the VOs used for query and display(possibly using ESS or SOA Components to push events to separate Data stores, but initially using a single DB).
I could not find any information on implementations of this in ADF, pros and cons, etc.
I would like to know:
Does what I am attempting makes sense in a ADF world? Why/Why not?
What challenges that may arise when using ADF in this case.
Offhand? I think you are over-engineering this. I would start with what ADF Architecture problems are you trying to solve with CQRS?
ADF has 4 "stacks" - ADF BC is the Data stack - EO/VOs based on tables/views and you can create VOs's based on web services if you need to integrate with SOA services ADF Faces is the server-generated UI Layer. ADF Controller handles page to page navigation. ADF Model is a data abstraction layer that sits between ADF BC and ADF Faces and allows for data movement and manipulation in the data layer by the view layer w/o direct connection - keeping the layers/tiers separate.
To manipulate a VO you either manipulate a Model Binding Iterator - which references the VO row set iterator and/or expose custom Java behaviors directly on the VO (not my chosen design) or on the Application Module (my choice) which can then be exposed to the UI via button/link or direct execution, while maintaining the separation of UI and Model and Data layer.
All this code is generated and maintained for you by JDeveloper wizards and tooling and editors. So only custom code need be added.
So, ADF implements a form of Model-View-Controller design pattern.
I do not see what problem ADF presents that you want to solve by adding yet another layer of abstraction in CQRS.
.
My team is considering using an up to date version of Entity Framework with a WinForm or WPF application which will be downloaded by users and installed on their machines.
This will connnect through WCF to our database, and the app will use LINQ queries through EF to interact with the database.
Is this secure? Can the application be reverse engineered, and a competitor see our database structure and business rules?
Is this architecture acceptable? Or if the risk is high, should the structure be abstracted behind an interface?
I imagine it depends a bit on how your WCF service is going to work. Webservice or Windows Service? Encryption? If you are not encrypting and you are serializing your returned objects in XML, it is possible someone could snoop that XML stream, and get an understanding of the structure of the entity (Pretty sure mapping information or Storage Layer information is not included in the serialized entity).
As far as Entity Framework goes, assuming an attacker cannot get to the edmx or the resulting EDM constituent files, and they can't get access to the database directly, you should be good. Entity Framework EDMs compile pretty similarly to other assemblies. So long as you secure the transport from service to client, you should be good.
we are currently building our first large application with Silverlight 4 (using PRISM) and Entity Framework 4. Now I'm having a general question about persisting view model data.
Suppose I have domain objects which translate to EF4 entities with multiple associations (Entity having collections, having collections again etc..). What would be the best way to persist those graphs during / after user actions? Would it be better to write more granular repository methods like "AddEntityToParent" and "RemoveEntityFromParent" or just take all the data from the view and push it to a "SaveLargeParentEntity" Method?
Can I "cache" the view model items for child objects in Silverlight and push it all down to EF4 later or would I have to make a granular update for every single item changed in the user interface? Any good advise? I hope my question was clear enough. Thank you.
You are actually making a choice between basic CRUD operations and working with object graphs. I would choose second approach because CRUD operations over web service can be very chatty.
When working with object graphs send over web service you have to deal with detached behavior. Detached entities + object graph couses some troubles when updating relations. The best approach usually is to load the whole graph before update (get attached entities) and merge received graph into attached one - it will correctly track changes for you.
But because you are using Silverlight which is stateful you can also think about using Self tracking entities (STE). STEs are able to track changes after they are detached from EF ObjectContext. So you can return object graph consisted of STEs from web service to Silverlight application, make some changes to STEs and send same object graph back to web service. Applying changes from STEs will handle a lot of work for you. Be aware that STEs are not the best solution for services which should be exposed to general web applications or non .NET clients.
I have a legacy dot net application (now migrated to .net 2.0).
We need to convert this application to silverlight.
Problem here is the datalayer. All the methods from the datalayer return datasets.
The entire web application is using datasets for databinding.
Now the questions are:
Can I use the same datasets for silverlight pages also?
Or do I have to create a wrapper around the datalayer?
Or do I have to change the entire datalayer architecture (like returning collections etc)?
Please suggest the best possible way.
Thanks,
SNA
Unfortunately, DataSets aren't supported in Silverlight 2 (and afaik aren't coming in Silverlight 3).
I'm going to assume that your current data layer has methods like GetTopCustomers that return DataSets, then the client application can modify that data and re-submit it to a data layer function like UpdateCustomers that takes a DataSet as a parameter and then submits changes to a database. If this is the case I think you'll have a tough time writing a wrapper because you'll be on your own for enforcing referential integrity and tracking changes on the client side. It's certainly possible but I think it'll be more pain than its worth. So imo creating a wrapper around your data layer would be equivalent to changing the entire data layer architecture to return collections, etc.
You best bet for a data layer is .NET RIA Services, which ships sometime in the Silverlight 3 timeframe. It's a huge leap over the current technology, ADO.NET Data Services, in that it adds change tracking and a DataSet-like "context" for the client. It also allows direct sharing of code between ASP.NET (or any part of the full .NET Framework) and Silverlight so your business rules can be run on both the client side and server side. Rewriting your data layer may not sound appealing, but I think it'll spare you much pain and you'll get a huge return if you choose .NET RIA Services. If that choice doesn't fit the other option is to use ADO.NET Data Services to ship the data back and forth (combined with a wrapper for your current data layer) or to write your own custom WCF services to provide CRUD operations (again with a wrapper on your current data layer).
Good luck!
If the goal of your conversion is to create a Silverlight version of your application with the least amount of change to your business logic layer, then a wrapper is your answer.
This is a lot of work in Silverlight V2, as you probably know. If you'd like some detail, here's a blog post. You will end up rolling your own serialize/deserialize/zip/encode layer for transferring the data to your Silverlight app.
Silverlight 3 isn't out yet, but close from the rumors. And this functionality is present in V3 (from what I hear).