|
ok, 
|
|
|
|
|
Great tools. However, with hibernate annotations *.hbm.xml" files aren't need anymore. Check it out.
|
|
|
|
|
thnks, can u give me the link to check it? 
|
|
|
|
|
|
Hi
I would like to thank you all for the contributions that you have provided my answer. I would like to know what sort of architecture can i use for delivering a business system to different clients. For example I might have, say a accounting system that i would like provide to different clients, which employees cloud computing concepts. I would really like to know what is the best architecture i can use for multi-company architecture systems using C# on the .NET platform.
Thanks in advance
|
|
|
|
|
sijimann wrote: I would really like to know what is the best architecture ...
One that fits the business needs of the targeted customer base.
Naturally one must first determine what the targeted customers are. Then one must figure out what the requirements are for the product(s).
None of that has anything to do with architecture.
|
|
|
|
|
Hi
I would like to thank you all for the contributions that you have provided my answer. I would like to know what sort of architecture can i use for delivering a business system to different clients. For example I might have, say a accounting system that i would like provide to different clients, which employees cloud computing concepts. I would really like to know what is the best architecture i can use for multi-company architecture systems.
Thanks in advance
|
|
|
|
|
sijimann wrote: I would like to thank you all for the contributions that you have provided my answer. I would like to know what sort of architecture can i use for delivering a business system to different clients.
"Loosly coupled, modular, distributed architecture."
sijimann wrote: For example I might have, say a accounting system that i would like provide to different clients, which employees cloud computing concepts. I would really like to know what is the best architecture i can use for multi-company architecture systems.
Not an architecture, but a design-pattern. It's called a strategy-pattern. You'd create an abstract base class, define abstract methods for insert, update, open and close-statements. Then you'd encapsulate the first strategy into a class called "LocalMysl" and another for "Azure", and derive both from your base-class. Use a factory-pattern to instantiate the correct strategy on your behalf, similar to below
MyBaseClass data = MyDataStrategy.Create("Azure");
data.Select();
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Dear All,
i want to develop a new asp.net web project,how can i proceed,can u tell me an example
|
|
|
|
|
Go to www.asp.net/[^] where you will find lots of samples.
Use the best guess
|
|
|
|
|
bnraj1528 wrote: how can i proceed
Collect requirements.
Create an architecture.
THEN decide on technologies.
|
|
|
|
|
1. Install on your deployment machine
-Microsoft web server IIS to store your ASP pages and other application files
-Microsoft SQLServer as database server
2.Implement 3-tier Design pattern
3. Have Microsoft Visual Studio or Express Edition of C# or VB on your development machine.
4. Read about ASP.NET, C# or VB.NET, and ADO.NET
5. Ask questions!!!
|
|
|
|
|
I am interested in knowing how you design your Domain Model and its persistance layer.
Particularly I design the Domain Model completely independent from any other logical application layer. As a matter of fact, it is oblivious of any other logical layer.
In that case I do create a service layer that acts as a proxy and sends domain model objects to the persistence layer.
I've seen Dependency Injection/IoC to perform the persistence, having the interface defined in the Domain Model, but I never really liked this approach, because it creates a small dependence of interface implementation by the persistence layer.
Do you have "Save" methods on your Domain Objects?
I'd appreciate if you shared your thoughts.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Hi,
If you are using relational database system like MySQL, Oracle, consider using an Object-Relational Mapping framework(ORM) that implements Data Acess Layer(DAL) design pattern . TopLink, Hibernate, ADO.Net, Java JPA, just to name a few, are popular ORM Frameworks. These frameworks abstract DBMS access and handle all database CRUD for you, and do much more. For example using Java JPA, you would save a domain object as follow:
EntityManager em;
em.persist(BookDTO);// BookDTO is the object to be saved in you database. BookDTO must be annotated as an Entity( @Entity) as far as JPA is concern. You can apply Dependency Injection/IoC to inject the EntityManager in your component.
To use DAL patern organize your Domain Model into Business Object(BO) and Data Transfer Object(DTO), and utilize an ORM framework of your choice.
Bakary Konate
modified 4-May-13 16:06pm.
|
|
|
|
|
Hi,
At work I have created a homebrew framework ColdBlood with various object oriented design features; one is persistency.
In the specification (interface) of each object type we differ between properties, references, child and children. We do this using different attributes (in C#). A property can have the optional flag Persistent enabled, which means this property is serializable.
All the specification attributes are compiled into some info classes for fast lookup e.g. by the serializer/deserializer.
This design means a complete separation of persistency specification and serializer/deserializer implementation.
Currently, we use a serializer/deserializer implementation with multiple ToBytes and FromBytes methods. The resulting byte data can be transfered to/from files or sockets.
Kind Regards,
Keld Ølykke
|
|
|
|
|
Is this the forum for asking questions about USB ?
I'm implementing the USB stuff in firmware, and frequently the rules (particularly the protocol) don't make sense from the documents I'm reading.
|
|
|
|
|
> "Is this the forum for asking questions about USB ?"
No. Try Hardware & Devices
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
|
|
|
|
|
Thanks, headed over there now
|
|
|
|
|
pls tell me some good book of arm cortex m3
also i want to work using embedded c so if someone can tell me some good book that will corelate the two
|
|
|
|
|
|
Hello,
I have a begginers design issue.
I'm building an layered application(Presentation layer, Business logic layer and Data base layer).
I have three entities in my application:customer,staff member and vendor that all of them deriving from person.
The user can add new customer,staff member or vendor to the data base(using UI).
My question is which layer is responsible for the next tasks:
1.Validating user data
2.Saving customer,staff member,vendor in to the DB.
3.Retrieving customer,staff member,vendor from the DB.
4.Perform other DB related manipulation with customer,staff member,vendor.
5.Which classes i need to define to perform the above tasks.
I'm new in to object oriented programming so thru the current question i am trying to understand the concept.
Thanks
|
|
|
|
|
columbos14927 wrote: I have three entities in my application:customer,staff member and vendor that all of them deriving from person.
Vendors are almost never "people". They might have sales people representing them but those can change.
Also customers can be companies and thus not "people" either.
columbos14927 wrote: My question is which layer is responsible for the next tasks:
Business layer.
|
|
|
|
|
columbos14927 wrote: 1.Validating user data
a) client side input validation should be in presentation layer.
b) Server side input validation should also be in presentation layer.
c) Business rule validations should be in business logic layer.
columbos14927 wrote: 2.Saving customer,staff member,vendor in to the DB.
Actual data base CRUD operations will be in Data access layer but on successful validation the operation should be done in Business logic layer.
columbos14927 wrote:
3.Retrieving customer,staff member,vendor from the DB.
4.Perform other DB related manipulation with customer,staff member,vendor.
Again, the db layer should contain the data access logic and db entities. The actions should be triggered from business logic layer.
Perhaps these article could be a little useful for you:
Creating ASP.NET Applications with N-Tier Architecture[^]
YaBlogEngine - A Tiny Blog Engine written in ASP.NET/C#[^]
Twenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore, Dream. Discover.
|
|
|
|
|
What are peoples' experiences with software design like?
I'm a firm advocate of the 6 P's: Proper Planning Prevents Piss Poor Performance, which to me means having a clear idea of what you want to achieve, and the necessary oversight to be able to make informed decisions.
For this purpose I find UML incredibly useful. Component or package diagrams help me determine my solution structure, decoupling of components, separation of concerns, reusability etc and completely prevent circular references.
Before I touch VS to set the solution up I make sure I've got this down, even if it's only a couple of projects and a test project. It's like I documented it before I even started.
I'm a bit baffled by some of my colleagues who expend a lot of unnecessary time and effort trying to keep their 100+ project solution in some sort of check without some sort of visualised overview. Just trying to add a single interface requires a three hour discussion involving everyone (6 developers, 18 person-hours, almost half a person-week) from two teams whereupon the only conclusion that's ever been reached in one of these productivity abyss meetings is "we need to add a new assembly" because their lack of oversight has made their solution so tightly coupled and interwoven that it's the only way short of taking everything apart and putting it back together again.
In my experience, when groups of developers have to resort to mentally storing lots of abstract information in the absence of a visualised overview, nobody can make informed architectural decisions and the solution grows organically and totally unchecked until the dependencies either get so complex that nobody knows what to do, or you run into a circular reference and people start throwing in arbitrary assemblies as a hacky workaround.
I've taken to going into discussions with the other group armed with a package diagram of their solution so I can tell them where to put what in their work. If I don't do this, each meeting descends into chaos with various people trying to compile lists or matrices of references which is exactly what the package diagram is representing. Afterwards you hear murmurs of "an overview diagram like that wouldn't be a bad thing", but nothing gets done about it unless I do it for them.
What do other people think?
How can I motivate my superiors to take software architecture seriously and value the advantages a bit of forethought will bring?
|
|
|
|
|
There's the problem of writer's block when using diagramming tools. The visual noise of icons/widgets in software tools I find very distracting. (such as Microsoft Visio)
I find it easier to think away from a computer completely, and use pen and A3 artist pad, and use my Boogie Board to write down changes/new approach when I'm not directly working on a problem.
I get stressed out staring at computer screens for hours and that's my reason for getting away from them.
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
