I'm busy prototyping a training management app using the DevExpress eXpressApp framework & Domain Components. This paradigm uses interfaces to specify domain entities, with default implementation logic generated at runtime, so that I can effectively enjoy multiple inheritance in my business entities.
I'm curious as to what sort of diagram I could use here to communicate my design assumptions to my client, without requiring me to build and deploy too frequently merely to confirm my assumptions etc. Hopefully fellow SO users familiar with this framework and it being used like I am doing can shed some light on this.
I felt that your question is a duplicate to Design and Modeling for DexExpress eXpressApp Framework. Basically, you will be able to model individual domain components using built-in Visual Studio modeling tools. It works pretty well with interfaces. Probably, you can also build a custom modeling solution based on an open source Liekhus ADO.NET Entity Data Model XAF Extensions tool.
Finally, since you are using XAF (and I believe you are also a DevExpress customer), I suggest you contact our Support Team to get fast and guaranteed assistance on XAF or any other DevExpress products.
You can model with a class diagram but what is generated at run time can not be modeled. I mean that for example if you have a model then you use the Model Driven Development in order to generate a code from your model then the generated code is not anymore your model but only the code like your run time classes.
Hope this help.
Related
What type of UML diagram should I use to model the parts of a web app?
For instance, lets say my parts are as followed:
Server
Database
Web App
Multiple APIs
The web app interacts with all the other parts in some way. From my research, the best options seem to be either component, deployment, or sequence.
Here's a general idea that I'm going for with my diagram, but I do not know which UML diagram this would best be represented in.
If you know the diagram I should use, I would like to know how each part is represented in the diagram. For example, in a deployment diagram, I know that a server/database would be nodes. And, APIs would possible be artifacts?
For designing a web app (or any other type of software application), following a best practice Model-View-Controller (MVC) codebase architecture, you first need to make an information design model, typically in the form of a UML class diagram, defining the model classes, or the "model", of your app. The "view" (or user interface) of your app is based on the model.
Your diagram attempts to model the deployment architecture of your app. But this question comes after choosing a codebase architecture and an information architecture.
You can find more explanations about the architecting process, and the code of several example web apps, in my book Web Applications with JavaScript or Java, which is also available as an open access online book.
This depends a lot on what you're wanting to model and communicate. All of the diagram types you mention would be useful ways to describe a web app. Each focuses on a different aspect of the web app -- component models are about software component structure (database, web app, apis), deployment models show how instances of these components are deployed into deployment nodes (servers, devices etc). Like Thomas says, this is a very broad question -- in essence you are asking how should you describe your web app's solution architecture which is not a trivial exercise. Is there something more specific I can help with -- can you narrow down what it is you want to show about your app?
Your start with the component diagrams is fine. Generally your question is too broad to be answered here, but a few bread crumbs anyway:
In a next step you can describe the single components which are hosted inside the single nodes. You can make the nodes navigable (means you have a composite diagram showing their guts) so you can place component instances showing their interfaces. The latter can be shown with either lollipops or as stereotyped classes which the single components implement. Following that you can break down components in a similar fashion showing how the components are implemented with various classes and how these realize the single interfaces. It's possible to show the interfaces outside the components and <<delegate>> them inside the specific classes.
The story goes on, but it's too big to be told here.
I'm a beginner in DDD and am facing a little problem with architecture.
Our system must be able to export business data in various formats (Excel, Word, PDF and other more exotic formats).
In your opinion, which layer must be responsible for the overall process of retrieving source data, exporting them in the target format and preparing the final result to the user ? I'm confusing between domain and application responsibilities.
And regarding the export subsystem, should implementations and their common interface contract belong to the infrastructure layer ?
Neither Application nor Domain layer or any other 'layer'. DDD is not a layered architecture. Search for onion architecture or ports and adapters pattern for mor on this subject.
Now to the core of your problem. The issue you are facing is a separate bounded context and should go to a separate component of your system. Lets call it Reporting. And as it's just a presentation problem, no domain logic - DDD is not suitable for it. Just make some SQL views, read them using NHibernate, LINQ2SQL, EF or even plain DataReaders and build your Word/whatever documents using a Builder pattern. No Aggregates, Repositories, Services or any other DDD building blocks.
You may want to go a bit further and make all data presentation in your application to be handled by a separate component. Thats CQRS.
I usually take the simple approach where possible.
The domain code implements the language of your domain - The nouns, verbs etc.
Application code creates poetry using this language.
So in your example the construction of the output is an application concern, while the construction of the bits that the application will talk about (since you don't mention it) would the the domain concern.
e.g. if the report consists of sales data, that things like dates, bills, orders etc. would be abstractly constructed in the domain, while the application would concerned with producing documents using these.
Am Afraid If am Overdoing things here.
We recently started a .Net project containig different Class Libraries for DAl,Services and DTO.
Question is about our DAL layer we wanted a clean and easily maintained Data access layer, We wanted go with Entity Framework 4.1.
So still not clear about what to opt for Plain ADO.Net using DAO and DAOImpl methodolgy or
Entity Framework.
Could any one please suggest the best approach.
It depends on how much work you want to put into creating your own customized DAL. It is always better to use ADO.NET and your own implementations, but this also includes maintaining and optimizing it and treating complex cases such as concurrency, caching and the mapping of you BO, the DAL and the Database.
If you want to concentrate more on business value and functionality you might decide to go with Entity Framework (now 4.3 released and 5.0 to come). The advantage would be that you use a DAL that was carefully tested and that already contains solutions for concurrency, caching and mapping.
But I would hardly suggest using the Repository and Unit Of Work patterns on top of it to abstract the usage of Entity Framework out of your other layers. Then you would have the possibility to later completely change the underlying technologies without any impact on the other layers (you could replace EF with your own ADO.NET implementation if you see that the performance is not as good as it should be for example).
It depends on the type of application that you need to build and on its performance requirements. Using EF could really reduce your work and give you much quicker results. It also depends on the development teams capabilities. If you only have senior developers and architects working on the project then you will create you own DAL easily. But for beginners it is really hard to implement a good, optimized and robust DAL.
I hope that helps !
I've been using ADO.NET and DTO combination in DAL ever since i remember and i love the fact that i control the entire process of creating entities and methods. However that comes with the price of having to write classes for every entity and methods for every stored procedure. Which i don't mind, but recently i have discovered PLINQO for LINQ to SQL and I'm loving it. It gives you ease of creation/updating of Classes based on your Database schema while allowing for high levels of customization. Its basically LINQ2SQL on steroids.
I also liked nHibernate but i think it had steeper learning curve than PLINQO.
I'd give PLINQO a try if i was you
I am researching to start a new project based on Liferay.
It relies on a system that will require its own data model and a certain agility and flexibility in data management as well as its visualization.
These are my options:
Using Liferay Expando fields and define their own data models. I must do all the view layer.
Using Liferay ECMS adding patches creating structures and hooks that allow me to define data models Master - Detail. It makes much easier viewing issue (velocity templates), but perhaps is the most "dirty" way.
Generating data layer and access to services with Hibernate and Spring. (using Service Factory, for example).
Liferay Service Builder would be similar to the option of creating the platform with Hibernate and Spring.
CRUD generation systems as OpenXava or your XMLPortletFactory
And now my question, what is your advice? What advantages or disadvantages do you think would provide one or another option?
Thanks in advance.
I can't speak for the other CRUD generation systems but I can tell you about the Liferay approaches.
I would take a hybrid approach.
First, I would create the required data models as best as I can with the current requirements in Liferay Service Builder and maintain them there as much as possible. This would require that you rebuild and redeploy your plugin every time you changed the data model but would greatly enhance performance compared to all the other Liferay approaches you've mentioned. Service Builder in that regard is much more rigid and cannot be changed via GUI.
However, in the event for some reason you cannot use Service Builder to redefine your data models and you need certain aspects of it the be changed via GUI, you can also use Expandos to extend the models you've created with Service Builder. So, it is the best of both worlds.
On the other option, using the ECMS would be a specialized case and I would only take this approach if there is a particular requirement it satisfies (like integration with the ECMS).
With that said, Liferay provides you many different ways to create your application. It ultimately depends on how you're going to use your application.
What's the difference between UML-Modeling and UML-Design? Or is it the same concept?
Thank you.
It's the same thing. Both refer to planning out your app (and documenting it) using UML.
Not really, even when both are part of the Structural Model (aim to model the static structure of the scenario), they use different objects.
The Domain Model instances are real-world objects. It is concerned with the problem domain and attempts to create a useful working model of the domain in which you are creating a solution for.
On the other hand, Design Model instances are software objects, which may be technology frameworks, databases, user interfaces, etc. you are using to get working software. You can say that Design Model is inspired by the Domain Model.