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.
.
Related
I have been trying to learn more about Uncle Bob's Clean Architecture from blogs, article, and videos.
If I were to use a database in this architecture, then what should the UI (as a framework such as web or form) know about the database? Or more generally, how should data flow between two or more pieces/parts that are in the same layer?
For example, The UI would talk to my adapter(s)/gateway(s) to interact with the business entities. To Read/Write, I can see that the UI could call whatever class/classes that can access the database and pass in the adapter(s)/gateway(s), so that it can interact with the business entities.
public class SomeUI
{
public static void Main(string[] args)
{
SomeAdapter adapter = new SomeAdapter();
SomeDataAccess db = new SomeDataAccess();
db.Save(adapter);
}
}
public class SomeDataAccess
{
public void Save(SomeAdapter adapter)
{
//Interact with database
}
}
public class SomeAdapter
{
//properties
}
Many of the articles barely vary off of this one (https://subvisual.co/blog/posts/20-clean-architecture). I have not found a good article that covers how pieces that are in the same layer should work with each other. So, articles referring to that would be an acceptable answer.
This does not appear to violate the Dependency Rule, but it feels like I am not doing something right, since I am making a dependency between my UI and database. I believe that I may be over-thinking the concept, and I believe it may be from hammering away at learning the 3-tier architecture (UI -> BLL -> DAL).
You ask:
If I were to use a database in this architecture, then what should the UI (as a framework such as web or form) know about the database? Or more generally, how should data flow between two or more pieces/parts that are in the same layer?
There is no such term as UI component in Clean Architecture. In Clean Architecture terms, the UI would be the presentation layer or the delivery mechanism, decomposed in the following components:
The view model generator (or the presenter to use Uncle Bob's terms), which is in charge of encapsulating the business rules for the UI. This should access the business model in order to generate the view model from it. The business model is passed to the presenter's method inside the interactor response object by its caller, the interactor.
The view model which holds data for the view and passed to the view indirectly via for example an event.
The dumb view which is now decoupled from the domain model and all layers, displays data of the view model.
Decomposing that this way insures better testability, better SRP and more decoupling with application, domain and infrastructure layers.
So your presentation layer should know absolutely nothing about the infrastructure layer.
Maybe you got confused by examples using some kind of Web Form component/library? This kind of component propose interconnected functionalities each in relation with several architecture layers: domain, application and presentation… So Web Form components are particularly delicate to adapt satisfactory in a Clean Architecture. Due to this inflexibility, I'm still struggling figuring out what is the best way to integrate a Web Form component in my Clean Architecture implementations...
Finally, to make it clear, you said:
For example, The UI would talk to my adapter(s)/gateway(s) to interact with the business entities. To Read/Write, I can see that the UI could call whatever class/classes that can access the database and pass in the adapter(s)/gateway(s), so that it can interact with the business entities.
It's not UI's responsibility to interact with your entities but as its name suggest it's interactor's responsibility (interactor = use case). Interactor are meant to encapsulate application business rules, they represent the application layer. They can CRUD your entities via the Entity Gateway which is your adapter to the infrastructure layer which could be an ORM, a REST API or whatever...
Edit #1:
Since a picture worth a thousand words here is Uncle Bob's UML class diagram representing the structure (and the data flow between the concerned components) of the Clean Architecture:
Edit #2:
It seems to me that your representation of the flow of control in a Clean Architecture is kind of reversed. Taking as reference the above diagram and Uncle Bob's analogy:
If you don't want your code to be dependent of a thing, make this thing a plugin.
(Said otherwise, make that thing the client of your code that you want independent from it.)
In a Clean Architecture, you want the presentation layer, or more contextually, the delivery mechanism (Controller + Presenter + ViewModel + View) to be a plugin of your business layer (which is composed of components on the right side of the communication channel boundary).
I have been doing more research into other examples of clean architecture.
(source).
From the diagram above, it looks like App (business entities and use cases) talks back and forth with Delivery (Externals: UI). The Delivery is used to talk to External (Externals: DAL).
Delivery is where you implement the delivery mechanism of your application itself. Delivery is where your app is integrated with external data sources and shown to the user. This means in simplest terms the UI, but it also means creating concrete versions of the external objects, such as data jacks, and also calling the actions of the app itself.
-Retro Mocha
So, that leads me to believe that yes the code example at the top is valid, but I am still open to hear if anyone else has more to provide on the answer.
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().
If my question isn't clear, please help me improve it with comments.
I'm new to Delphi and dbExpress and I'm just getting acquaintance with TSQLDataset, TDataSetProvider, TClientDataSet and TDataSource classes.
The project that I'm working on uses this components in a way that feels strange to me. There is a huge data module unit that contains lots and lots of the quartet of classes previously described. I'm guessing that there are better (and more modularized) ways of doing this. DataSnap is used only to place this data module in a server application, so the clients access the data through it.
So, let me try to explain some of my doubts:
What is the role of each one of this classes? I read the documentation but I can't get a practical insight on this subject (specially about TDataSetProvider).
Which classes should be in the data module and which should be in my forms?
Is it possible to create an intermediate layer to abstract my business model from my database setup (maybe creating functions that return immutable datasets?)?
If so, is it wise to use DataSnap to do so?
I'm sorry if I'm not clear enough. Thanks in advance.
Components
TDataSource is the bridge between data-aware controls and the dataset (TDataSet descendant) from which they are to get their values.
TClientDataSet is one such dataset. TClientDataSet can be used in isolation, for example to access data contained in xml files, but can also be hooked up to a TDataSetProvider.
TDataSetProvider is the bridge between the in-memory TClientDataSet and the actual dataset that takes its data from a database through some kind of driver. In Client Server development you will usually see a TRemoteDataSetProvider (name may be different, I don't work with these components that often), which bridges the gap between the client and server.
TSQLDataSet is the actual dataset getting its data from some database.
It would feel strange to me to see this quartet all in one executable. I would expect the TSQLDataSet on the server side hooked up to the TRemoteDataSetProvider's counter part. However, I guess that with an embedded database it could be a way to support the briefcase model, which is where TClientDataSet is really helpful (TClientDataset is very powerful, that is just one of its strong points.)
Single datamodule
Ouch. A single huge datamodule is lazy programming or the result of misconceptions about how to use datamodules. It is perfectly normal to have a single datamodule that "hosts" the database connection which is then used by various other datamodules that are more tightly focused on aspects of the application.
Domain abstraction
With regard to abstracting your business model, dbexpress and datasnap should really not be anywhere in your business model. They should be part of your data layer.
TDataSource, TClientDataSet and custom TDataSetProvider descendant(s) can be used to leverage the power of the data-aware controls in the UI while still keeping the UI separate from the business model. In this case the custom TDataSetProvider would be the bridge between the client dataset and the collections and instances in the domain layer.
Even so, I would still expect to see a separate data layer, using TRemoteDataSetProviders or straight TDataSet descendants (like TSQLDataSet) to provide the domain layer with its data.
The single huge data module you mentioned could be part of that data layer, with the client datasets providing the business layer with its data. As you also mention TDataSource as part of a common quartet, the application was probably developed in a RAD-data-aware fashion where UI controls are basically hooked up straight to database columns/tables.
If you want to transform this application to have a more layered architecture, tread carefully and slowly. Get to know the current architecture first and get to know it well enough to see the impact that this kind of transformation would have. The links provided by Serg will certainly help you there. Pawel Glowacki has written extensively about DataSnap.
The project you are working on is a Delphi Multitier Database Application
Your question is too wide for SO and hardly can be answered in its current form - you should learn to understand the underlying architecture.
You can start from video tutorial by Pawel Glowacki:
http://www.youtube.com/watch?v=B4uxLLIUddg
http://cc.embarcadero.com/item/28188
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).